Even so, how could that DAOâs decision stop;
It may be hard to win a vote of the DAO, but if that DAO canât stop anyone creating and running modified node software itâs toothless.
1 Like
Thanks @DavidMc0 that helps. However the video seems to imply
Is not something available today?
It could not be a liquidity bridge (as one side is zero liquidity), so it would need to be a bridge with external validators (hacks) or a very slow and tech heavy setup.
So I am still struggling here to see a bridge that works with a zero liquidity token and a liquid token and doing so in a trustless way thatâs not super hard to implement or use.
2 Likes
In this case, in the early days anyone who wanted to trade to ÂŁ would need to use the ERC20 version.
If that person held ERC20 Network Token, theyâd just send it to a DEX / CEX and sell it. Easy.
If this person held Native Token, due to faster on-network performance, lower store cost (lower TX fees etc), or they earned it on their nodes & want to sell to fiat, they would simply use a bridge to swap them 1:1 with ERC20 Network Tokens, and then sell them on a DEX / CEX
Anyone could try to collect Native token & swap to ERC20 and sell all day, but given that any other holder could also swap their Native for ERC20 & sell them, people wonât be just giving them away. Also the way the bridge is designed should ensure that there will always be sufficient ERC20 to support all redemption requests (e.g. Native Token is only created when ERC20 Network token is locked/burned & vice versa).
1 Like
Various options are available today and widely used with ERC20 and other crypto tokens with hundreds of billions of dollars of value locked.
I recently bridged ETH to Arbitrum, and Binance chain & itâs dead easy.
But itâs of course not available yet for bridging ERC20 for Autonomi Native tokens because Autonomi and the community havenât developed it yet.
An early system could perhaps work with 2 types of bridge;
-
One or multiple slow setups with some centralisation & probably fees for large, KYCâd mints and redemptions using a trusted custodian (e.g. Alt.co?). Some stablecoins use this kind of thing to sustain a peg)
-
A liquidity bridge, with liquidity kicked off by the big slow mints / redemptions that become node earnings etc, bootstrapping liquidity.
Once thereâs enough liquidity, the big slow, centralised mints / redemptions would become less necessary, but still needed to keep everything in balance & provide off-ramps for when demand for native token drops, or increases vs the ERC20 version.
It might also be possible to implement a decentralised approach, where ERC20 tokens are locked in smart contracts, but thatâs only really possible if some basic smart contracts are either available on Autonomi directly, or groups of nodes that run EVM nodes alongside Autonomi nodes & can validate mints / redemptions to lock & unlock ERC20 assets on their chains.
I donât have near enough knowledge of Bridges, EVM, Autonomi data types etc to come up with a technical solution, but it seems clear to me that this is only a technical challenge and not economic.
I like this concept, though I think both should alway be accepted, but a bias can be put on price so ERC20 could be priced slightly lower / higher than native depending on which youâd prefer to receive.
4 Likes
This is way outside my technical grasp of that area. It all reads very complex to me. I hope there are ways and there are folk with the knowledge to do that, but it seems far from simple.
2 Likes
I donât see why that would be the case either⌠I could see nodes might want to charge less for Native token payments, as the fee will be lower / nonexistent, and it may be necessary to pay with native for micro transactions etc.
But if anyone really wanted to pay with ERC20, what node wouldnât accept it as long as any premium vs Native covers the cost of Bridging to native (which the node software could optionally do for you once implemented).
In this scenario I think Native token would quickly become whatâs used for storing stuff on the network, and ERC20 would purely be used for;
- long term holding if perceived risk of Native Token is higher in early years, or if hardware wallet support wasnât yet ready for Autonomi Native tokens
- Using on/off ramps
2 Likes
So node operator wants to exit, and sets nodes to only accept erc20. So what happens when all 5 nodes closest to a chunk being uploaded do that but the person uploading only has native token?
What happens if the ERC20 price goes up for a week and so many node operators want ERC20 and uploaders mainly have native. What happens then, does the network slow down and mainly clients with erc20 are the only ones who can upload chunks to nodes taking erc20 and not upload chunks where all the nodes for that chink only take native. Sounds like a potential nightmare and lockup of the network at times
Sounds like its assumed uploaders will have both tokens all the time to use.
5 Likes
Agreed.
But itâs likely a very small challenge vs creating the Safe Network.
Given itâs the biggest thing that stands in the way of achieving the Native token, I think itâs worth either the community or team getting in a bridging expert to look at how it might be possible to bridge between ERC20 and Autonomi Native⌠though that expert would also need to interface with an expert on how Autonomi works, so likely a team dev.
4 Likes
I donât think they should be able to accept only native/ERC20, but could set a small price differential, so give a quote for both types, and the uploader pays whoever in the group offers the lowest quote in their preferred payment type, which may be a premium if e.g. nobody really wants to receive ERC20.
Iâm assuming bridging is in place (so anyone can swap between either type on a whim), and that people respond to incentives, so arbitrage works to keep the 2 prices aligned.
Also, if bridging could be automated in the client, nodes can accept anything & the client can bridge it to whatever they want to hold.
2 Likes
The solution to that would be users, that want to exit, set their nodes to both currencies, but set their price higher in NT, than in ERC20. This way, no one is locked.
Later, seems like it will be so. And in the beginning, everybody will have only ERC20 anyway.
3 Likes
I want to be in one of these! 
Why not a community team? It sounds like pro publico bono thoughâŚ
9 Likes
You may not but a simple mod can make it so and that mod could become widespread. And its not something other nodes can force either really. The other nodes only see the client not accepting the quote
1 Like
Unfortunately, if everybody wants NT and everybody have ERC20, the prices will drift away, goodbye 1:1?
2 Likes
I suspect all bridge type solutions end up there.
2 Likes
That seems like an interesting approach, and makes sense, if it requires a different set of specialisations than what the current team have in place.
As long as itâs not undermining the token value, why not?
I wonder what might be âin itâ for such a team to spend resources to develop this system? If itâs a community led & funded team, that would make sense, as theyâre invested in making Autonomi all it can be, and many hold the token, which would benefit from this.
Do you have in mind some kind of mechanism to ensure the network doesnât get clogged by spamming if there are no fees?
Sounds interesting⌠itâd be great to hear more thoughts and details on how the Transaction data type could be used as a currency, and how it might work (e.g. with having known supply / auditability, while also having no history etc).
1 Like
A bridge makes 1:1 work⌠any solution without a 2 way bridge / swapping mechanism would lead to lasting price differentials between the tokens. With bridging, that goes away.
Not at all, if thereâs 2-way bridging in place. Anyone could quickly and easily swap their ERC20 for Native at any time, or vice-versa.
If, in a few yearsâ time, the ERC20 were still needed as an on/off ramp, or for off-network storage of tokens, there will be demand for it, and arbitrage will ensure prices of ERC20 and Native stay very close. What would change is the circulating supply of each as a proportion of the total circulating supply.
If demand for the ERC20 eventually drops and Native has on/off ramps etc, a âfinalâ mechanism could be introduced to burn ERC20 and issue Native, which is a 1 way mechanism⌠but that wouldnât be wise until there is sufficient trust in, and adoption of, the Native system to âBurn the bridgeâ & go fully native.
2 Likes
There are many approaches, but I am dead keen to not get invovledin details design right now. Time is short, but then folk will say itâs all had wavy and thatâs horrible as well.
Basically I am in a no win situation, folk want details and then debate each issue with many folks, so nothing gets done ;-( Anyway
- Make transactions depend on parents before able to spend again
- Donât care about spam, let it happen, but make it unable to harm the network
- make the network able to handle billions TPS and not care
- Lots more, tons more
It already allows transfer of a value form one entity to another, Thatâs its purpose.
I personally donât care about audibility in the trad sense. Instead make the system so simple itâs simple to audit the code.
OF course folk can collect all transactions, create a DAG And check, that that is like taking photos of every cash transaction in the planet and tracing that. I donât get why the crypto sphere is so hung up on this. I prefer simple code, like ants, cellular automata, i.e. simple rules we cannot compute going forward but that can perform apparently super complex tasks.
Anyway I am dead set on not designing this right now, we have a network to launch and seriously itâs mental if we try and detail design any future advances right now.
Anyway I hope this snippet helpsâŚ
11 Likes
Sure, I guess itâs possible that once a native token became available, some portion of nodes might run nodes that aim to shut down the ERC20 option by not accepting it.
But, if someone is willing to pay a bit more to use ERC20, you only need one node in 5 to say, âIâll take a bit more payment to store thatâ. Though, if nodes start preferring native, I donât see ERC20 making much sense to pay for data storage as it should be slower and more expensive to use.
1 Like
I think itâs a bit difficult to be optimistic. This comms strategy (if it can be called a strategy) has been pretty woeful. IMO, news like this (I.e., that the Network will âlaunchâ without a native token, essentially making it like any other ERC20 project) should not have been shared without a clearly detailed plan that addresses the obvious concerns the community would and does have.
Itâs kind of shocking. This (seemingly) ill-thought-through announcement paired with the several glaring misses regarding the publicly shared roadmap to the âlaunchâ thatâs supposed to be taking place in a matter of weeks, is quite disheartening. Where were the partnership announcements? Where were the hackathons? And yet, these misses were never truly acknowledged and addressed. IMO, admitting that beta would need to take longer than planned in order to get to the native token would have been better receivedâparticularly in the absence of a cohesive, cogently articulated plan for this ERC20 path.
- As it stands, it sounds like eMAID/MAID will only be 1:1 exchangeable with the âlaunchâ ERC20 token, and therefore eMAID/MAID will not be 1:1 exchangeable for the native token, should that ever be made.
- It also sounds like MaidSafe has no plans to create the native token, and is hoping random âteamsâ of people will create potential contenders for the native token. That sounds like chaos to me. Also, it makes the purported 50% reduction in max supply meaningless.
If I am misunderstanding the above 2 points, it would be great for MaidSafe to clearly state that 1) eMAID/MAID will be 1:1 exchangeable for the native network token, and 2) MaidSafe will own creating and delivering the native network token (even if that means hiring people to do the work).
How different things were back in Q1 when so much was promised. Back then, I had hope that a sense of strategic discipline and order were being introduced into the process. I hope that things turn around. But then again, itâs been years of hoping that things turn around.
17 Likes
I hope people are happy with âhigh levelâ concepts at this stage rather than demanding details for something that isnât fully developed yet! And I hope we all win by you sharing your high level concepts on how this might work
Thatâs the ideal - if the fundamental principles are so simple thereâs no room for any bug hyperinflating supply etc.
Understandable, but thanks for sharing what you have.
6 Likes