Update 16 November, 2023

We’ve been busy this week patching up the testnet for relaunch. One cause of the errors we saw last time was replication going to too many nodes, causing increased memory usage. In turn this caused rapid price changes meaning clients got stuck in a re-spending loop.

We’ve put in a couple of PRs to stop these excessive replications now. We’re testing them internally, and further debugging potential issues.

Tooling improvements are under way to help us track royalties across testnets and get baseline metrics to compare against. And we’re looking at more subtle testing techniques with concrete goals than simply lobbing up a couple of gig to see what happens.

We are also looking into a simplified payments regime proposed by @ansleme.

The goal is to simplify payments and remove the need for retries and repayments on price changes. The signed quote provides a verified price agreement between the client and node.

In summary it looks like this

  • Client asks node for price quote, node replies with price + timestamp + signature
  • Client gathers total payment amount including royalties
  • Client sends payment to node along with the signed price quote
  • Node verifies signature is valid and timestamp is within last 10 minutes (for example)
  • If valid, node stores data

The key points are:

  • Node signing removes the need for repayment in case the price changes between the quote and payment as the node knows it agreed to this quote as it created it.
  • Timestamp allows node to reject excessively old quotes (as now).
  • This reduces the need for retries and cached payments in the client (as long as the client is trying to upload within the contract expiry time).
  • Only a single payment and royalties transfer instead of multiple.

The timestamp here is a contract between the node and itself to make sure the clients aren’t mispaying. It is NOT a contract between the client and the node.

Thanks again to everyone who has helped out with testnets and testing. We hope to be able to bring you a longer-lived testnet iteration soon.

General progress

As well as the above payments proposal, @anselme has continued to refine the pay-one-node setup, which requires a bit of refactoring.

@Roland has been tinkering with the testnet deployer so we can pull out more useful info when launching testnets, including getting the genesis multiaddress and node stats. He also created a PR for the deployer to add resiliency to Ansible tasks, so it will ignore errors deploying up to 10% of nodes. In testing, a 2,000-node network with unreachable nodes was still able to deploy successfully using the ignore_unreachable option.

Roland also fixed an issue with client timeouts which was identified by @loziniak

@bochaco has completed a change that means that the royalty fee now amounts to 15% of storage payments instead of the one-nano-per-address approach we’ve been using. We also check the total amount received with the notifications and not just the number of notifications. Anselme has updated the wallet software accordingly.

@Qi_ma has split royalty payments across topics to reduce resource usage, and has been working on tests to assess its impact.

@bzee looked at how to gracefully stop the nodes with signals in addition to RPC and is looking at libp2p to see if there are things to take into account for logging off, rather than using killall or Ctrl-C. He and other team members are also reading up on libp2p Sybil protection.

And @joshuef has been hard at work putting an end to those pesky excessive replications.

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!


Hey I can’t be first to plant this flag :checkered_flag:

Now read

Thanks for the update Maidsafe devs

Can’t wait for the next testnet, missed two because I thought I had the luxury to try the next day :sweat_smile:

Keep hacking super ants


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

And also to the forum members who are testing our testnets to help them improve! :horse_racing:

And congratulations to @19eddyjohn75 for being first to post this week. In the history of our forum he is the user that has given the most likes! :+1:

Here are the top 3 users with the most likes given on the forum all time.

@19eddyjohn75 36.5K likes
@Nigel 31.8K likes
@Southside 30.4K likes


Thanks team for the hard yards this week. Sounds like a new testnet is just around the corner :fireworks:

Hope everyone’s had a good week. I’ve been busy in my garden sowing the summer veg. :slight_smile:

Cheers :beers:


Thanks as ever to all concerned with this latest update.

One teensy weensy point though…

I thought “time” had no place in the network ? :slight_smile:

Not that this relevant here - roughly 10 mins , +/- 10 secs say, should be perfectly adequate here so getting network wide consensus on 10.00000 mins is simply not an issue.


My read is that this is a timestamp by the node for the node. Same node, same clock, so not a network issue? But I could be misunderstanding both comments.


Great work and hope we get more good news for the end of the year :crossed_fingers:


Yup, that’s correct. I had the same Q, but it’s just a duration check for the node, not two nodes deciding agreeing what time it is. The Network still has no concept of, nor need for, time.


This makes me a reassured and happy bunny. :carrot: :carrot: :carrot: :carrot:


Another great update thanks to all the team for keeping the git hub turning.

Can’t wait to try out Royalty v3 :slight_smile:



I can’t wait to put Royalty on trial myself.

The charge sheet will be very long indeed.


Thanks for the update!

I was wondering if and when we can expect an update on this primer? https://primer.safenetwork.org/ I remember reading this back in 2017!? Which was very helpful to get a better understanding of the complete picture. I must admit that with all the changes in the updates over the last few years I’ve lost the complete picture and would love to dive into it again.


Great job, gentlemen! (Speaking of which, I always wonder if there are any women here? If there is a lady active here, please make yourself known!) :wink:

A big thank you to the team for all their hard work and to all the testers for helping to improve the network! :clap: :clap: :clap: :blush:

I was also surprised by the timestamp, but fortunately it’s just a technical issue, everything is on track :slight_smile:

I agree with the call, there really have been a lot of changes since February and it’s hard to keep up with them until the end, so it would be good to update at least the most important parts of how the network works, so that Primer gives forum users a quick overview of where we are.

  • Node verifies signature is valid and timestamp is within last 10 minutes (for example) price is within last few price changes.

My suggestion a few testnets ago was almost exactly the same as this except the time keeping. I suggested that the nodes keep a record of their last few prices they charged and if the quote is within that range (no need to be exact in practical terms) then it accepts it. That way there is no timeframe and allows for longer timeframes if the price isn’t rising fast which one would expect in a network that is working properly.

Glad to see the suggestion being explored as I personally feel this is a solid way to solve the potential excessive retrying. If the node used its last few prices (maybe 3 stored) then time is not a factor and in a large system one would expected it to be longer than a few days for 3 price changes. That would allow clients to get prices before uploading a file that will take the client days to upload.


Great work!

A question:

Does the client asks node for a price quote for every chunk as the upload progresses or for a total for a file of X amount of chunks before it starts the upload?


What I have yet to comprehend is how the pricing in terms of $ will work as there are 2 variables: the price of SNT in USD and the price of storage in SNT. If one goes up and the other down, nothing has really changed

Yes I know the network will not care about the price of SNT in USD but the users will. And if the price of storage in terms of SNT is swinging around people will lose trust.

Unless my groceries are priced in SNT too….


This is where the human comes in.

The network does not care about £ but humans do. So what happens is the network increases the AMOUNT of SNT needed to get as many nodes running as it needs. The human operator decides if that is enough for them to keep the computer running. Whether that is 1 or 100 SNT, it’s the £ price that matters to the human.

While this all happens, the network knows it needs fewer computers (lots of space so pay less) or more computers (short of space so pay more).

So if SNT is high, there will be a lot of free space on the network as folk chase the dragon.


Yes there are :wink: