Thank you for your response and I appreciate it. I have patiently read all the information in the topic and the statements of the team and the community but not all the questions were answered there.
I want to firstly point out that I very much appreciate your 18 year journey that you have been on and the work of the whole team and many of the most committed members of the community, I also understand very well that the decisions of the board were not easy and are legitimate because regulations, legal issues, commitments to investors, requirements of confidential partners etc. required it and I even expected these problems that the team had to face because this is a project different from anything that has been created so far and operates in an extremely difficult business environment. I respect these decisions and wonder how to bring the community together to support you, Bux, Jim and the team to alleviate the (understandable however) bitterness of many and avoid a rift in this fantastic community.
I read all your (and not only your) statements again after this reply and did not still find the answer to my question - how will the team lead the development of the Native Network and the target Token, will this be based on a working network with the ERC20 Token?
Basically, the answers to all the questions asked were: we don’t know, it’s unspecified, it can’t be calculated. This means that a network that works with Native Token will come into existence at some point, but for the time being, not even an approximate date can be given, which is perhaps why there is so much doubt among people as to whether a Native Network will ever be available.
I wonder if it would be possible to run two Autonomi networks, and I don’t mean a bifurcation but two parallel, twin networks:
-
The first would be the original network with the Native Token, which would allow development and testing as originally conceived, the team could develop the token on it and innovate, eliminate problems and bugs etc, and developers could test and develop applications on it, it would not be burdened by regulation and legal requirements because the token would not be listed anywhere and would have a clearing value, and it would be created by all those willing to create it who are looking for the utility value of the network, not just tokenomics, you could say it would be a technology sandbox, and this would facilitate testing and experimentation without complicating the work and operation of the commercial network (ERC20),
-
The second would be a prepared network with the ERC20 Token implemented, meeting adaptations to regulations and legal requirements, which would allow partners’ expectations to be met and would be developed in accordance with the adopted tokenisation, with TGE implementation etc., as in the Native network, the team would carry out development work and developers would develop applications using the adopted tokenomics,
Sure the idea seems ridiculous and maybe the thought is just very silly but it occurred to me:
-
perhaps separating the work on the Native Token network and the work on the ERC20 network would allow the objectives to be achieved more easily, as each network would have different scalability and technological priorities, I am not in a position to assess this, but numerous statements indicate that the changes made to the ERC20 network will cause many complications, which will probably not facilitate the work on the objectives set,
-
the Native network could use the dev forum, so as to simplify the flow of information, transparency of work etc, and the work on the ERC20 network would remain in the community forum, I know that for the team this could be some discomfort but it is possible that overall the transparency of work on individual problems would be more beneficial though,
-
As the two networks would be twinned, all errors detected and updates developed could be mutually implemented in the common part (i.e. the data storage layer),
-
the costs of the Native Network appear to be small for the project, as the infrastructure is created by the users, and the scale of the network would ultimately be an interpretation of its sophistication and market assessment, the team would have freedom in many areas of the work, and with the risk of attempts to bifurcate the network greatly reduced, full control would remain in the hands of MaidSafe,
-
I don’t know what the future of these networks could look like, but the market could judge for itself which solution is better and which it wants to use, I have no idea if this is possible and it’s just speculation, but - maybe it would be possible to merge these networks in the future, since the storage layer would be exactly the same and each network would have its own token with its own genesis, while in the current assumptions about the future there is a flexible option offering the choice of Native or ERC Token,
-
no one could accuse you or the Board of Directors that the original Native network has been abandoned for any interests, and that it will not be developed.
I don’t know if I’ve drifted too far away with this idea but could it at least be worth looking into?