Update 12 January, 2023

First off, many thanks to everyone who participated in our testnet last week. We’re counting it as a success since all our recent changes worked as expected and the network remained stable until it was full. Good stuff. :tada:

Some of you spotted that we required 7 elders to respond to the client rather than 5. That’s because we were being intentionally harsh in testing connections and making sure everything is working properly. We’re busy rolling out more improvements and will drop another testnet on you once those are in. But the “all elders must respond” and similar “strict mode” requirements will stay about for a while still.

In the background the team have been working on the finer details of token distribution. @JimCollinson takes us through where we’ve got to.

General progress

@qi_ma and @roland continue to simplify the relocation flow. This is one of the more complex areas to get right. First the elders must notice a node has gone and vote on that fact. They then need to vote on membership change, notify a candidate to replace the missing node and then exchange messages so the new node has all the information it needs before data is transferred to it. So, lots of moving parts and the simpler we can make it the better.

To monitor these complex goings on, we need a solid monitoring observability system, which is what @chriso is on. Presently he’s working on getting OpenSearch and OpenTelemetry working with Amazon ECS.

@Roland is also refining a GUI to be used with safe to remove the need to use the dreaded command line. Should be demo-able soon.

@Joshuef continues to pare down the number of communications we’re handling between nodes. It seems we are contacting nodes which are outside of the section and then waiting for replies which never come, causing errors.

@bochaco has finished removing the send-stream from the Cmd::SendMsg, introducing a new command to separate flows that are meant to be exclusively on streams.

And @anselme is turning his attention to some DBC refactors. More about that at a later date.

Updates to plans for Safe Network Token Distribution

Hi Folks. A bit of an update for the Token Distribution RFC as we round on some solutions.

There are a lot of moving parts; from technical capabilities, design propositions, operational considerations, to legal feedback. A lot goes into tweaks that may seem small on the surface, so we thank you for all the support, patience, and your extensive comments and feedback in the latest RFC 0061 thread.

Token emission and the Genesis supply

The biggest change here is an answer to the question on whether we mint the total supply at Network Launch, and how and when the 70% of remaining tokens are created and then distributed.

Minting the total supply at launch necessitated either the Foundation or the Network itself holding and then distributing these tokens over time, both of which have significant challenges we want to avoid, chief among them security, but also the equitable distribution of a considerable slice of the economic power.

A reminder that the aims were A. gradual release of the Remaining Tokens, while at the same time B. having the tokens be in the custody of the Network.

The solution here is not to have them minted up front at all, but rather have the Network emit them over time—creating them as the Network grows—and paying them out to Node operators as Resource Supply Rewards.

While it is still a chunky bit of work that is unlikely to be complete without delaying the Network inception, we are satisfied it is a reasonable design solution within reach, and one that can be implemented via a Network upgrade post launch.

So the Genesis supply, circulating at launch, will therefore be 30% of the Maximum Supply, and the remaining will only begin to come into being after a satisfactory, secure, and robust solution can be shown and rolled out; and then these tokens will drip out to Network contributors over an extended period, likely decades.

Other minor changes

You’ll also notice some other minor tweaks, such the language describing eligibility for Network Royalties as an App developer; more precision on the SNT allocation for shareholders; and directly stating that eMaid will be redeemable 1:1 for Safe Network Tokens, just the same as the original flavour MaidSafeCoin.

Maximum Supply

You’ll note the change in the term from Total Supply, to Maximum Supply, which is in order to better articulate the changes around token emissions, and the proposed genesis supply.

One thing we’re proposing remains from the RFC, is the change from the original Safecoin cap of 2^32 to the maximum supply of 4,525,524,120. This is to resolve the quirk from the original crowdsale that saw an overmint of MAID.

But It’s important to note that:

  • No investors, crowdfund participants, nor MAID holders lose out.
  • The long touted 1:1 Maid to SNT like-for-like swap remains; which is easy to describe and comprehend, and very useful to maintain for usability when on-ramping to the Network with MAID.
  • Due to fundamental technical changes, tokens are no longer tied to network addresses. This allows for things like divisibility, but also gives us the freedom to specify a suitable maximum supply.
  • The max supply of MAID has been known and advertised for nearly a decade now, displayed on every exchange and blockchain app going, along with the 1:1 redemption terms, so it’s not a surprise.
  • It’s a cleaner solution and we feel it’s easier to explain the 5/10/15% allocations given to the initial distribution pools, and their share in the overall economy, than to repeatedly examine why MAID is now 10.37%.

We know this is a choice some of you won’t like, but it’s one between two aesthetic/ergonomic options, both of which arrive at the same result, so we’ve chosen what we feel is the path of least resistance.

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: Bulgarian

As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!


First!! wooww


And Second some 18 minutes after update posted



Well done team great to here so much is going on and can’t wait to get a try of the GUI when it’s demo ready :slight_smile:


Excellent work, great update.

IMO, whatever get’s us to the gate at this point is gold. This horse wants to run and the world needs it like no other.

Keep pushing hard team! Let this be a year to remember.

Cheers :wink:


Nice decision has been made about maximum token supply and supply at the beginning of the network.
Remain the question about distribution Resource Supply Reward .


What question was that?


To see how much you get from Network Royalties and Data payment.
Like discussion over the past years.
If there is some ratio to speed up distribution during earlier stages, …
The current RFC describe where from where to payment and royalties goes, but not how the values are calculated.


Ah yes, got you. Yeah, that would be a subject for another paper.


Right now implementations for important features fails for years despite possibility to have infinite wipes for test networks.
And then, post launch, another important feature will be done on live network correctly on the first try?


Things can be tested in stages, first with testnet then in dummy form in the real network. So it’s not exactly ‘first try’, and is not something that is as complex or tricky as getting the base network to operate in the first place.

You’d have a similar risk if you held back and then launched a full network that includes this feature from the start. In fact that seems riskier to me


Thanks so much to the entire Maidsafe team for all of your hard work! :racehorse:

Looking forward to the next testnet. :racehorse:


Thanks to all involved for this update.
Special thanks to @JimCollinson for this work on token emission, The diagram makes it a lot clearer. While his work on this and the Foundation in general has been very valuable/essential, I must admit I’m looking forward to Jim being able to devote more time to the UI/UX in the coming months.

And thanks to @Dimitar and the other mods for the new chat feature.


…munching popcorn…


OpenAI summary

The summary is about a testnet that was conducted and deemed successful. The team is continuing to work on improvements and will release another testnet in the future.

They are also working on the finer details of token distribution and have made changes to their plans for the distribution of the Safe Network Token.

The biggest change is that they will not mint the total supply at launch, but rather have the network emit them over time and pay them out to Node operators as Resource Supply Rewards.

The Genesis supply will be 30% of the Maximum Supply and the remaining will begin to come into being after a satisfactory number of nodes have been reached.

The team is also working on simplifying the relocation flow, monitoring systems, and a GUI for safe. They are also reducing the number of communications between nodes and working on DBC refactors.

Privacy. Security. Freedom


Thank you Maidsafe team for officially stating this!

As a US investor, I was waiting for a statement such as this publicly, prior to engaging in buying or selling eMAID, and/or converting existing MAID coins to eMAID.


Thx Maidsafe devs for the update,

That’s really great news that the last testnet remained stable. :partying_face:

Nice overview @JimCollinson

Keep hacking super ants


the exact number of sub-units may be increased to provide further divisibility. :clap: :clap: :clap:


This is a horrible solution. The hardcap of 2^32 should be maintained. Instead, just report the actual percentage of Maid issued and absorb the difference in the genesis distribution.

No it’s not. This is the most ridiculous solution you could have proposed. The solution is amateur and disappointing. You really got it wrong here. I’m critical because I care about you all.

Do you think increasing divisibility is increasing supply?

For instance if bitcoin went from 100,000,000 sats per bitcoin tomorrow to 200,000,000 per bitcoin did the supply increase?

In my opinion definitely so.

In which case changing the number of whole SNT is almost irrelevant as the total number of unique tokens is as yet undecided. (Or more precisely open to change with potentially further divisibility)

1 Like