Network Rollout Update
The Autonomi Network, formerly known as the SAFE Network will be ‘released into the wild’, to become publicly accessible on: Tuesday, 29 October, 2024.
This date marks the beginning of the Network’s full roll out, with the launch completed by the end of January 2025 through Autonomi’s Token Generation Event (TGE).
What exactly is going live on October 29 2024?
From October 29, Autonomi, in it’s new public environment, will be ready to:
Store data that’s quantum encrypted
Handle data uploads (using token)
Pay nodes hosting data (with token)
Access to the Network will be available through:
Command line interface (CLI)
APIs (with toolkits for support)
Node Launchpad (Beta rewards disabled)
The WebApp (for individual/private user upload/download)
Nodes will be able to receive payments for hosting data via the Network’s test token, this test token will be an ERC standard token. Data uploads will be paid using the same test token.
During the roll-out all tokens earned by nodes will be tracked (visible ‘on-chain’), any test token used for data being uploaded to the network will also be visible. The earning and spending of these test tokens (‘earning’ will be for hosting data and ‘spending’ will be for uploading data) will be rewarded through an exchange of the test tokens (earned and spent), into a ‘Network Token’ allocation, following the TGE of the same in late January 2025.
Are we ready? What is the risk with launching in October?
Yes, we are ready to put the Network out and into the wild, we need to do this to observe how it behaves without the MaidSafe team being at the center of the test-net environment, as it has been with the ‘Beta Node Reward Program’ (e.g. during this testing program the ‘Nanos’ earned by hosting data on nodes, were sent to a MaidSafe wallet so that they could be registered for rewards).
From October 29 2024 and ahead of TGE the Network, with your help, we will test the integration between Autonomi and the ERC-20 implementation. We will also use the opportunity of having the Network out in a fully scalable/public environment to identify further bugs that need to be addressed, along with any improvements to the Network’s performance that can be identified thanks to real-world conditions.
In summary, post launch in October, and throughout the months of November and December the MaidSafe team will be focused on:
Network stability, troubleshooting of issues and code reviews
Preparation for the Network’s TGE (including token exchanges/redemptions)
Encouraging activity on the Network with:
Incentive schemes (to include data interface i.e. WebApp)
The builder program
Marketing and partner announcements
In January 2025, the Network will transition from using Test Tokens to implementing the official Network Token. While data uploaded before this transition and the TGE will remain encrypted and secure, it will not be permanently stored on the Network.
Why isn’t my data permanent until after the TGE?
Data not being perpetual on the Network until after TGE is due to the fact Autonomi will need to switch from using Test Token to using the ‘real’ Network Token post TGE (i.e. the network will be switching over but data will not/cannot). This process does not affect any of the security aspects connected to the data itself, pre or post, the Network Token being live.
Why should I bother uploading data that will be lost when the Network switches at the TGE?
Prior to the TGE, uploading data will be incentivized through a user being rewarded for doing so - it is important that the Network has data to host and that the experience of both uploading and downloading is thoroughly tested and optimized. In line with this Maidsafe will be running incentive programs ahead of full launch, focusing on - token testing, platform engagement and the Builder Program. More details on each of these will be shared in the coming weeks - but there will be incentives to run nodes.
What do the nodes store and what are the rules for nodes storing data?
There are four rules and four data types:
Data types:
Chunks
Register
Transaction
ScratchPad
Data Rules:
Chunks check hash of content == name (note: all 32 byte arrays and all the same. Meaning xor address == sha3hash == any 32byte array).
Registers check updates are signed by the owner and merge them (they are built for this).
Transactions, if duplicated, duplicates are stored and never overwritten — this is a form of double-spend attempt and prevention that is truly decentralized and allows for mass parallel payments across the Network.
ScratchPad address = XorName(owner publickey), check updates are signed by the owner and increment the version.
Autonomi will be launching with an ERC standard token (ERC-20) as its Network Token, why?
Autonomi’s native token and payment system was intended to utilize a DAG-based UTXO (Unspent Transaction Output) model, offering the following advantages:
Advantages of the UTXO Model
Lightening Fast / Nano Payments: The system would allow for concurrent processing of non-conflicting UTXOs at incredibly high throughput.
Highly Anonymous Transactions: It would enforce the use of one-time addresses, enhancing privacy through improved anonymity.
No Gas Fees: There would be no need to charge gas fees to incentivise validators, unlike blockchain systems.
Integration with the Storage Network: The system would also offer a native integration with the Autonomi storage solution by treating each CashNote as a native data type within the storage network.
The risks of the UTXO approach for launch
Taking a holistic view of the market, audience and space that the network needs to secure to thrive, there are several avoidable issues that, by electing to sequence the solution and its intended payment solution, we can avoid:
Integration & Accessibility: As a novel approach there is no out-of-the-box integration with other tools and platforms across the broader cryptography ecosystem (wallets, DeFi platforms and centralised exchanges).
User Confidence: With new payment technology integrated into the storage solution the Network will be introducing new/potential attack vectors, elements of untested variance.
Questions around Security: Auxiliary services such as an EVM bridge (required for users to exchange their network token via exchanges), will require extensive security validation to avoid exploitation.
While these aspects can of course be overcome with time, investment and resource, all of which MaidSafe has, they may severely limit the network’s initial accessibility and appeal, limiting its ability to achieve adoption and scale, and for the Native token to exist and thrive.
Ultimately we need to prove the storage solution viable and desirable, we can then move to a native (as opposed to network) token, tackling the public challenges that that will entail.
I feel like I’ve been let down regarding my privacy with an ERC-20 token, can you convince me I’m wrong?
A Native Token for Autonomi is still on the roadmap, and while Maidsafe has advocated a DAG-based UTXO model for the network, which enforces a one-time address for all transactions, the need for integration with blockchain-based marketplaces (CEXs, DEXs) needed to be considered in order to support the reward (payment) incentives required for launch, initial adoption and the beginnings of scale.
The issue of initial scale, mainly speaks to the potential ‘isolation’ of a network launching with a small audience and a novel token. Concerns around stability and security, as well as traceability of payments (with less familiarization with tech) may also be coupled at the outset with people finding it difficult to exchange the tokens they hold and have earned for traditional currencies. These aspects would not be good for adoption or engagement/desirability (based on earnings). This of course would apply much less when/if there’s high demand for the network and its token, with the weighting between ‘effort’, ‘reward’ and perceived ‘risk’ starting to balance.
It is also important to note that the rate of exchange (and the ability to exchange) earned/gifted Network Token is ultimately what will create/represent ‘real world’ value to the token earner/holder—especially in the early stages of the network’s life where the network token’s utility is still growing.
Speaking of growth—for those looking to try the network for storage, accessing the token (i.e. exchanging currency for/buying the network token), so that they can pay for uploaded data to be hosted, needs to be an as easy, open and demonstrable process as possible. The readily available (and somewhat battle tested) tools, resources and knowledge base associated with an ERC-20 token will be to great advantage here.
Before continuing on about accessibility, it is also worth noting that this strategy for launch comes in part, as a result of consideration around potential volatility of ‘privacy coins’ (based predominantly on legislative influences). A volatile network token would impact the network’s operation as a whole—i.e. the incentives to run nodes and assurances around data permanence. This instability/uncertainty could deter hosts, builders and users/partners considering storing their data or building with Autonomi.
The integration of an ERC-20 Network Token with Autonomi will require users to migrate their funds to a blockchain wallet. Users will be able to create an EVM-compatible wallet specifically for interacting with the network and cover gas fees using either ERC-4337 paymasters and/or zk-SNARK-based privacy protocols.
The connection between the uploader's address and the chunk address will not be revealed on the blockchain. Chunks are ‘Information Theoretically Secure’, meaning that a chunk has no link to another chunk and there’s not enough material in a chunk to allow for decryption. i.e. its encryption is beyond any algorithmic security. It is actually not possible to decrypt a chunk on its own. Similarly, the link between the node operator's receiver address and the node's PID remains undisclosed on the blockchain.
What are the implications of launching with an ERC-20 Network Token?
Nodes
Nodes will be paid in ERC-20 tokens and notified accordingly. Each node will have an Ethereum wallet address as its identifier. Node operators will be able to specify their own RPC (Remote Procedure Call) endpoints for their nodes, although a default RPC endpoint maintained by the foundation will be provided.
Uploaders
Uploaders will receive quotes from nodes, along with their wallet addresses and will be responsible for paying nodes in ERC-20 tokens. For large files with many chunks, a smart contract that batches payments for all chunks will be used to make the process more gas-efficient. Once a payment is made, the uploader will notify the nodes to check the blockchain - including a chunk or upload identifier in the notification message.
Endpoint
The Foundation will operate its own Ethereum nodes and provide a default RPC endpoint that nodes can use to read blockchain data.
Smart Contracts
There will be an upload payment smart contract to batch payments for chunks belonging to a single file. In addition there will also be a token smart contract to include additional tokenomic features in order to assist the stability and health of the network by adding features, sinks and utility to its token, critical for launch (i.e. desirability to run a node, supporting network growth).
Many folks are here for the storage and privacy aspects of the Network and want to interact with crypto as little as possible. What’s your reaction to that?
We are very aware of, and understand the sentiment, however there are two main contributors for our decision:
The network by design requires the incentives for running nodes to be meaningful. This, in turn, requires a connection between the network and a market. Ethereum has the most active and liquid market. It also provides significantly better scalability and lower fees, thanks to its L2 scaling solutions.
As we progress with our native payment development, we envision allowing data uploaders to choose the payment method between ERC-20 payment and native token payment. This will provide flexible payment options for both crypto native users as well as those who don't want to interact with crypto in general.
As mentioned above the Native Network Token is very much on the roadmap, this will be particularly important if we’re able to reach the scale that we have set out to. Ahead of then, and for that to happen, we will need to have early/initial adoption of the network.
What are the cost implications and what mitigations are being explored?
The MaidSafe team are continuing to explore the ways in which we can reduce gas fees further, as even with a Native Token on the roadmap, we need the ability to scale from launch. There are of course other ecosystems (such as Solana) out there—we have chosen to use Ethereum as it’s the most established with (as result) the lowest barriers to entry.
With an L2 implementation gas fees will also be low. By way of example only: Base chain currently incurs about $0.0014 per transaction with a single token transfer. In our experiment, a transaction involving 256 chunk payments will incur about $0.05 to $0.1 in gas fee payment.
Currently 256 chunks can contain up to 256MBs of data.
Another element we will be looking at over the coming months is chunk size, exploring the optimum size for Network performance and gas fee efficiency. Currently each chunk has the maximum size of 1MB. So 1000 chunks will be 1GB.
Once the Network’s native payment system is ready, users will have options to pay with either Network Token (ERC-20 token) or with the network’s Native Token.
What are the plans for MAID, eMAID and the rewards/token allocations that have been earned and will be earned through incentivised testing programs?
eMAID holders will be informed of a snapshot, which will allow the equivalent amount of Network Tokens to be airdropped directly into their wallets, effectively replacing the eMAID they hold.
For those who have earned a Network Token Balance through the incentivised testing programs—this includes the Beta Node Reward Program, as well as the upcoming programs for token testing, Network engagement and ‘Builders’, there will be a window to submit a wallet address for the tokens to be deposited into.
For MAID (Omni) holders, the MaidSafe team will be building an exchange interface that will enable you to take ownership of Network Tokens equal to the amount of MAID token that will be burned. These Network Tokens will be issued as an ERC-20 token, although the team will also provide the option for MAID holders to exchange their tokens with the Native Network token when it is ready.
Are there any further updates to plans regarding the Network's economy?
Yes. Upon releasing the last update to the White Paper earlier this year, the MaidSafe team were made aware of concerns around the level of discretion and control the Foundation would (potentially) have over the Network/Native Token. As a result steps have now been taken to address this concern (including automation).
There will be a reduction of maximum token supply (by 50%) and there will be updates to support token health (essential for the token-based network to scale and function). Further details confirming these aspects will be released in early December, with a final White Paper update released ahead of TGE in late January 2025.
The content of this update is hot off the press on Tuesday 10 September 2024, and accurately reflects the Network launch and rollout plans. The documentation on this site will continue to be updated over the coming days to reflect these plans, and give more details on the technical and economic implementation of them.
Last updated