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. 
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:
Russian ; 
German ; 
Spanish ; 
French; 
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!
