Update 4th April, 2024

Thanks as usual to the noble testers our first Technical Beta Network is still going good guns, and is proving as stable as we’ve come to expect. And some fixes and tweaks are in, based on your feedback and reports… so thanks again!

One minor snag is the faucet (our way of distributing tokens to testers to start things off in the testnets) which has had a bit of a wobble. Restricting the faucet output certainly helped stop the nodes from filling up so fast, as we had hoped, and lengthened the faucet’s lifespan. However, it now seems to have pulled a strop and fallen over.

The pricing mechanism seems to be working and we’re in a good place to get an update out that will adjust the cost calculation based upon the relevant records, as opposed to just the total count of records.

We have a new separate testnet to test potential changes over here. This will run alongside the stable beta network and allow us to test out ideas without having to bring the beta down.

PR corner

Many thanks to Foorack who suggested a tweak in sn_auditor to make the code show up properly on the crates.io website.

General progress

@chriso has updated the node manager readme, so be sure to give that a read if you want to run multiple nodes as a service. You may need to install the latest version of safeup before you can install node manager, if that’s your preferred route. Windows users also need WinSW He’s also been digging into the network update process and investigated an issue where Safe.exe is flagged as potential malware on Windows, as reported by the community.

@anselme made some tweaks and bug fixes to the DAG (the store of transactions) to allow for regular updates and saves. He introduced logging so we can see what’s happening there and fixed a problem where sections of the DAG were not being saved. The current thought with the DAG is to have DAG nodes running alongside testnet nodes recording all the transactions, and to see how that works out.

@bochaco continues to work on the account packet, the encrypted credentials stored on the network which allows users to authenticate themselves. Via the API, users can now encrypt and decrypt the locally cached recovery seed using a password. CLI is a bit more involved as each OS does it differently, but that’s coming. He is also looking at registers and how we access records back through time, and he fixed a problem with folders syncing.

@dirvine, @joshuef, @jimcollinson and @Qi_ma discussed potential solutions to spend spam, where an attacker might attempt to bog the network down with masses of small requests.

Qi also opened a PR allowing nodes to verify that quotes are really being sent by the node claiming to send it (a security measure), and another on tracking data stored at close nodes. Bad node detection is looking pretty solid now.

@joshuef has been ticking off tasks on the alpha network checklist.

Also on alpha, @roland submitted a PR to provide network versioning based on the git branch , i.e., if it’s the stable branch it will be beta compatible, otherwise a branch release would lock the network to that branch. He also shared a PR to implement sn_testnet_deploy network commands as a GitHub Actions, and fixed the bug that was causing handshake timeouts.

Finally, @jason_paul raised a PR to handle small chunks or chunks with zero length, and has been getting into the node-manager codebase.


First … . . … .


I think for now the best way would be to just introduce a small fee which has a relation to the network storage cost which is paid to processing nodes / groups. My idea is that the fee gets higher as nodes get busier. If not storage cost, then maybe another metric, which measures node business. This would be another incentive for reliable nodes and imo a fair solution to prevent spam. Ideally it should stay small enough to not become a problem (like BTC etc.) but high enough to prevent spam.


Great update keep the alphas and betas going!


Love this part!


Fantastic work to all the team I’m struggling to keep up with everything these days and I like it :joy:


Thanks so much to the entire Autonomi team for all of your hard work! :man_factory_worker: :man_factory_worker: :man_factory_worker:

And also to the volunteers working on the testnets! :man_factory_worker: :man_factory_worker: :man_factory_worker:

And also to the moderators! They are keeping me in line! :laughing: :laughing: :laughing:


Great job, well done to the team and all the test ants! :clap: :clap: :clap: :blush:

The pace is fast and I really appreciate the hard work, :point_left: :ok_hand: :slightly_smiling_face:
but it’s getting a bit chaotic, hard to keep up with the many topics, wouldn’t it be worth sorting out the activities in some way?

Maybe it would be worth putting something like a calendar at the top of the forum with the most important topics and events and the most important documents like the Roadmap, the White paper and the long awaited Primer?

I think when someone comes to the forum for the first time, they might feel a bit confused if the regular users can’t keep up.


Nice update team. Getting busier and busier as we move closer to launch. The excitement is only beginning … batten down the hatches :wink:

Regarding spam, how about little proof of work puzzles … start with none, but if a node get’s bogged down it asks for clients petitioning it to solve more and more puzzles. So not an always on proof of work, just activated by each node depending on number of requests. It makes the spamming clients bear the cost.

Wanted to add that @Toivo is working on a nice graphic to explain XOR space on the network --pressure is on now comrade :ant:! :rofl:

Thanks for everyone’s hard work. Eat well, sleep well, and enjoy a reward :beer: in your time off.

Cheers :beers:


@Dimitar is working on an “important links” list, perhaps the other things you suggest here could be rolled in?


It was a loose thought, but I think these three documents should be pinned at the top of the forum, then everyone could easily and quickly see the current state of the project, and many questions would be answered right away. Now, however, someone comes into the forum for the first time, or someone you haven’t seen for a long time, and starts asking questions, which creates a thread, which creates more and more content, which doesn’t necessarily help transparency.

If you are away from the forum for 2 days, when you come back you don’t know what to read and you often waste your time when you could be participating in tests or writing something constructive…


Thx 4 the update Maidsafe devs

It can’t get better than having a stable beta network and separate testnet to test out ideas.

Maybe spending @ the start of the Network should have a time delay to prevent spend spam or spending depending on resource provide to the Network…

These are really great times

Keep hacking and testing super ants


Hate to say it but the easy solution is to charge, even a nano would slow things down.

Maybe a challenge method could be introduced for spends not for storing data and royalties. The spends for storage & royalties are easy to identify since the node storing the chunk previous sent a signed quote and thus can be seen as such. Other spends will not have this and then can be subject to a challenge.

This challenge for non chunk store/royalty spends could take the form of
client: ask first node for challenge
1st node: return challenge and sign it including hash of spend in signing for proof to stop reuse.
client: ask 2nd node for challenge proving 1st node’s signed challenge
2nd node: return new challenge and sign challenge with previous signed data
continue asking other nodes. Ask as many nodes as deemed enough.
The spend can only be sent once this has been done. (Only needed for non chunk store spends)

Challenges can be real simple and need take little processing. EG add two large numbers. The purpose of the challenge is to remove any chance of the client guessing it.

The purpose is to increase the time taken for a single non-chunk-store spend. And lag times do this nicely.

I assume the nodes used are the same nodes that are required for the generating the spend in the first place. So now they have a second task occurring after the spend is generated. Need to use these to prevent the client asking nodes controlled by the spammer which happen to be on their local network.


It is so easy for sure, the unintended consequences perhaps not so clear.


After saying it for eternity, I thought let somebody else say it for once.

To be real honest, I’ve looked @ the unintended consequences since the nano was first introduced.
When you have a fixed 1 nano tx fee, the consequences are extremely benifical to the SAFE universe. Everybody their node can get paid 1 nano for processing a tx. There are even emerging properties lookie here Process Payments On Your Website | Fees & Pricing | Mollie

What your looking @ is 1 transaction through different payment methods, the funny thing is they all have a different price, a fixed 1 nano tx fee would almost looks like an electron’s location on the map of these payment methods. Hihi a $1B tx would get costly with these payment methods compare to the 1 nano tx fee it would cost to move that billion on the Network.

1 MAID would pack 1 billion tx’s, this would give merchants a guarantee, how much it would cost them if they started accepting tx through the Network and they wanted to send tx’s.

Moreover on the Network, I would suggest a new approach to altSAFE tx’s. I call it Hawking radiation, it’s pretty simple. Let’s say you create 2 satoshi SAFEbtc from 2 nano SAFE, but now you want to send 1 satoshi SAFEbtc and you got no 1 nano SAFE to send the tx. What should happen, is that they use the other 1 satoshi SAFEbtc and this takes care of the tx in exchange that it becomes 1 nano SAFE for somebody else again. Up until now I think, all tx’s were only powered by the native token no btc no MAID tx. Now it would be no SAFE, but 1 nano worth of altSAFE you can send, because the underlying token is still SAFE.

Eventually when the Network is big enough, of course SAFE tx’s would become free again, and altSAFE would always have a 1 nano tx fee. On the bitcoin lightning network there is also 1 satoshi and sum extra on top, 1 nano SAFE with no extra on top would finally give the atom a purpose on the Network.


Very true and the rest of my comment of course was not along those lines but perhaps an alternative that might spark some thoughts.


much more predictable transaction fees


Thx :gemini:

Remittance Costs: A Comparison

The cost of sending money abroad, also known as remittance costs, can vary depending on several factors. Here’s a breakdown from different sources:

World Bank: According to the World Bank’s Remittance Prices Worldwide database [World Bank Remittance Prices], the global average cost of sending remittances is 6.20% (as of September 2023). This figure represents the total cost, including:

  • Fixed fees: Charged by the remittance service provider for sending a certain amount.
  • Margin on exchange rates: The difference between the exchange rate offered by the provider and the mid-market rate.
  • Recipient fees: In some cases, the recipient might also be charged a fee for collecting the funds.

UNECE: The United Nations Economic Commission for Europe (UNECE) focuses on a target set by the Sustainable Development Goals (SDGs) to bring the global average cost of sending remittances down to 3% or less by 2030. This target specifically applies to sending $200 (or equivalent) [UNECE Remittance Costs].

IMF: The International Monetary Fund (IMF) highlights the variation in remittance costs depending on the specific route or “corridor” (sender and receiver countries). Their analysis shows the median fee ranged from 1% (Russia to some neighboring countries) to a staggering 25.8% (South Africa to China) in 2020 [IMF Remittance Fees].

Key Takeaways:

  • Remittance costs are a significant burden, with the global average exceeding 6%.
  • There’s a global effort to reduce these costs to 3% by 2030.
  • Costs can vary greatly depending on the specific countries involved.

Finding the Best Deal:

When sending money abroad, it’s crucial to compare fees and exchange rates offered by different providers. Here are some options:

  • Banks: Traditional banks often have higher fees, but they might offer better security and convenience.
  • Money transfer services: These services specialize in remittances and can be more competitive in terms of cost.
  • Online platforms: Several online platforms facilitate money transfers, often with lower fees and transparent pricing.

By comparing these options, you can ensure you’re getting the best possible deal when sending money abroad.