Native Autonomi tokens <> ERC20 2-way bridging ideas

Features
1

Purpose of this thread

With Arbitrum fees being the main / only real cost of uploading to the Autonomi network, and peaks of high fees emptying the wallets of some trying to upload, I would like to see Native token solutions emerge as soon as possible, and I expect I’m not the only one.

With the team rightly focused on the core network, native token & bridging may not be a team priority for some time.

So I thought I’d start this thread to share some thoughts and ideas about Native Token and bridging solutions and invite others to do the same.

I hope it’s at least interesting to some, and all the better if it ends yielding some stuff that’s helpful to the team, or leads to earlier development of a viable native token solution :blush:

My basic thoughts on ERC20 <> Native Autonomi Bridging

I feel the easiest / quickest way to a viable, decentralised, Native Token on Autonomi is via a 2-way bridge that effectively ‘wraps’ ERC20 ANT into a Native Autonomi based token, which can be transferred between Autonomi users / nodes / wallets without the need for paying an Arbitrum network fee.

This could also be used to ‘wrap’ any other ERC20 token to Autonomi, and possibly lead to the development of Autonomi based DEXs etc.

I think the following main functions are needed for a successful Autonomi <> ERC20 Bridge:

  1. Decentralised method of locking ERC20 tokens on ETH / L2
  2. Decentralised method of issuing Native Autonomi based tokens against verified locked ERC20 tokens
  3. Method of unlocking ERC20 tokens based on a verified burn of sufficient associated Native Autonomi tokens

In terms of difficulty, 1 is a know quantity and done all the time. 2 and 3 will probably be quite difficult & require innovation as there isn’t a spec for Native Autonomi based tokens, or known methods to mint them, or to burn them to redeem associated ERC20 tokens.

As someone with little relevant knowledge, I thought I’d try out Grok 3 to see what kind of proposals it could come up with.

Grok 3’s Bridging proposal

Grok made up a name for a conceptual Autonomi-native ETH L2 that I discussed with it prior to this proposal (AutoL2), which it suggested would offer greater flexibility, but be a lot more effort to implement than this. It also came up with an acronym ‘GET’ for its suggested Autonomi native ‘Graph Entry Tokens’.

After a little prompting it came up with the following proposal:

Proposal: Decentralized 2-Way Token Bridge Between Arbitrum and Autonomi

Purpose

The purpose of this proposal is to create a decentralized 2-way bridge enabling seamless conversion between ERC-20 tokens on Arbitrum One (e.g., ANT and other assets) and native Autonomi-based tokens utilizing Autonomi data types (e.g., GraphEntry-based GETs). This bridge will:

  • Facilitate wrapping of ANT into a pre-native Autonomi token ahead of the official native token launch by the Autonomi team.

  • Extend the same functionality to any ERC-20 token, broadening interoperability between Arbitrum’s EVM ecosystem and Autonomi’s decentralized storage network.

  • Maintain a high degree of decentralization to align with the ethos of both networks.

Overview of Implementation

The bridge leverages Arbitrum One’s existing L2 infrastructure and custom software on Autonomi nodes, implemented in three key components:

1. Arbitrum Bridge Contract:

  1. Function: A trustless smart contract deployed on Arbitrum One locks ERC-20 tokens (e.g., ANT, USDC) via a lockTokens(amount) function, emitting a TokenLocked event. It unlocks tokens upon valid burn proof from Autonomi.

  2. Decentralization: Fully decentralized, leveraging Arbitrum’s rollup security.

  3. Steps: Develop and audit an open-source contract, deployable in weeks.

2. Autonomi Nodes with Custom Software:

  1. Function: Autonomi nodes run an opt-in software module (e.g., in Rust, extending MaidSafe’s SDK) to:

    • Monitor Arbitrum events via multiple RPC endpoints (e.g., public and community nodes).

    • Mint GraphEntry-based tokens (GETs) on the Autonomi Network, stored as Chunks, with client-side stochastic validation (inspired by David Irvine’s vision).

    • Burn GETs when users return them, signalling the reverse bridge.

  2. Decentralization: High if widely adopted—target 50%+ of Autonomi nodes via ANT/GET incentives.

  3. Steps: Build and open-source the module, integrate into node software, incentivize uptake with rewards.

3. Decentralized Relay Mechanism:

  1. Function: Syncs Autonomi burns back to Arbitrum to unlock ERC-20s.

  2. Initial Approach: Use a 7-of-11 multisig committee of diverse Autonomi nodes to sign burn requests, submitted to the Arbitrum contract.

  3. Evolution: Transition to threshold signatures (e.g., 51% of bridge nodes) within a year, leveraging Autonomi’s “DISTANCE check” for sybil resistance.

  4. Decentralization: Moderate (multisig) to high (threshold), avoiding centralized oracles.

  5. Steps: Set up multisig with reputable operators (e.g., Autonomi Foundation, community), develop threshold signature protocol, audit and deploy.

Implementation Timeline

  • Phase 1 (1-3 Months): Deploy Arbitrum contract, launch custom software with multisig relay, test with ANT.

  • Phase 2 (6-12 Months): Scale node adoption, transition to threshold signatures, expand to other ERC-20s.

  • Future: Align with Autonomi’s official native token, potentially integrating client-driven proofs.

Outcome

This delivers a functional, decentralized bridge faster than a custom L2 (e.g., AutoL2), using Arbitrum’s ecosystem for ERC-20 locking and Autonomi’s network for native token minting. It supports ANT pre-native wrapping and broad ERC-20 interoperability, with iterative decentralization enhancements to ensure trustlessness.

Questions to move this thinking forward

So, this is just a discussion starter really, and I’d be grateful for anyone’s thoughts on;

  1. What do you think of Grok’s attempt at a proposal for a 2-way bridge for Autonomi? Does the ‘Decentralised relay mechanism’, or other aspects of this seem plausible?

  2. Is a 2-way bridge the easiest way to get a viable Native Token running on Autonomi, or are there other alternatives?

  3. Can you think of an easier / quicker way to get a 2-way bridge running than what I + Grok have proposed here?

  4. Might it be possible for a community team to get some of this done ahead of the team being ready to focus on Native?

It’d be great to hear any other rough proposals people have that could lead to viable solutions for 2-way bridging to Autonomi Native Tokens to be developed… and no worries if it’s only me who wants to talk about possible 2-way bridging ideas for Autonomi :laughing:

9 Likes
2

Thanks for kicking this off, @DavidMc0

paging @dirvine - as if you were not busy enough…

3 Likes
3

Isn’t the most difficult question here how to enable node payments in both currencies? The smart contract for price discovery is still on arbitrum and probably needs to be paid for in eth (?) official node binary just knows about ant…

1 Like
4

Humans will not want dual or more currencies to pay. Node operators will favour one over the other and we end up having to have bags of multiple currencies whenever we are uploading. Not going to work. Nodes will decide the best one and only accept that. OR perform arbitrage using this and one day accept one of them only and the next day another one only

Only bridges to/form will work effectively as on/off ramp, but native token has to be that to provide fee less transactions, once you are working with (wrapped or not) multiple currencies then by necessity need to charge fees. Image the massive arbitrage happening using fee less transactions.

2 Likes
5

I could be wrong, but I don’t think that will be a big challenge once there is a native token standard and wallet solution etc (Edit: and as Neo says, nides might prefer to receive only one. It’s likely that’d be native because it’s what uploaders would want to use to use less ANT to upload).

I expect the price checking function doesn’t require ETH from nodes when they’re putting a quote together, but more likely uses some API to get the data… but I could be wrong.

The challenge of getting a sub-network of nodes to cooperate to enable minting of Native Tokens, and coordinate burning to unlock the ERC20 tokens sounds like it’d be a much bigger & more complex challenge to me.

6

Autonomi have made it abundantly clear, on multiple occasions, that distractions are the last thing they need—yet here we are, surrounded by the same noise from the same voices. Is it really so difficult to let them focus and do their work in peace?

1 Like
7

I can’t imagine uploaders will want to pay with ERC20 once Native is available, as Native would be significantly cheaper, and probably quite a bit smoother.

If uploaders pay in native & increase uploading due to the benefits, I expect nodes will be happy to earn more with Native vs less with ERC20, and only deal with ERC20 for off-ramp / other ERC20 ecosystem stuff.

Did you read the first post of this thread? I said this:

I made this thread for interested community members to discuss potential solutions for Native token and Bridging while fully expecting the team to stay focused on what they’re focused on.

This needn’t be a distraction for the team.

It seems odd to think that the ‘features’ category of the Autonomi community forum is an inappropriate place for the community to discuss potentially beneficial features for the Autonomi Network.

2 Likes
8

Then why promote building in the complex mechanism for nodes to accept payment. Hmmm seems a waste then to promote it in the first place.

Also on this very question it has already been stated that there will only be one network token at any stage of tokens (ERC/native). (for payment of resources/ free transactions)

Now I fully agree that it’d be good to have multiple ways to on/off ramp, be it via bridges or another mechanism, as well as native bought and sold itself.

1 Like
9

I get where you’re coming from, I just feel that threads like this are nothing but a distraction.

1 Like
10

There is nothing in this proposal about changing nodes to accept payment - that would probably be easy; the proposal is about how to create a Native token that is backed 1:1 by ERC20 ANT, that could be used for payments without the fees and slowness of ERC20 ANT, and could be redeemed for ERC20 ANT if desired.

1 Native (wrapped) ANT is still 1 ANT.

David suggested multiple times that it could be a third party team that makes Native token work. But the wrapping means it’s still only ANT that can be used to pay… just wrapped in Native Autonomi based structure that avoids the downsides of ERC20 fees and slowness.

3 Likes
11

It’s realy a bad idea to develop a payment mechanism on this type of network architecture. Autonomi has been designed as a data layer, its not build to scale for whats required for payments.

Rather, just move to solana. You want the team to spend years to somehow build a better network for payments compared to whats out there? It’s not like you can just add a native token layer, there are reasons it was scrapped

12

A native token has been an integral part of the plan for over a decade.
I appreciate that solana may be an efficient payment solution and that you are a fan. Its going to be a hard sell though.

6 Likes
13

Not to mention when the (hoped for) world is using Autonomi and there are millions of payments per second from the 2 to 4 billion users. Any blockchain is going to suffer, that is why a digital currency is needed that is not blockchain based. If the “blockchain” solution will work then its not using blockchain for payments.

Not to mention you need a huge network of blockchain nodes just to support it. Blockchains are a very inefficient transaction system, whereas native simply keeps transactions slim lined in storage requirements and are just part of the data layer

7 Likes
14

Exactly my point, but we are on the opposite end. This network scales worse than a blockchain such as sui or sol or kas, far worse in fact. A payment layer, such as the prior proposed DAG will be multiple times slower if you want to propagate payments through the current network architecture

15

Aren’t you comparing the old tech and then saying the new datalayer transaction record type is the old type?

I think you maybe surprised by what is coming.

And scaling, well we have over 10 million nodes that disagree about scaling the data layer which transactions will be one of the data types.

The bugs with uploads are that bugs being fixed

4 Likes
16

The problem is payments require concensus

17

I do think you do not realise the process. And can your blockchain handle the load when the world adopts Autonomi.

5TB of newsgroups storage per day, for one tiny part of the internet storage happening (that was 10 years ago, prob 10 times that now)

5TB = 1 (4MB chunk) x 250 x 1000 x 5 x 3 chunks uploaded to store a day and each one a transaction.
5TB is 4.8 million transactions each day.

Now data centres account for many many times that being stored. Translate that to Autonomi and we start seeing the potential for billion or more transactions per day.

How many blockchain nodes will be required to process those transactions agreeing with each other. How much storage it duplicated across many (how many) blockchain nodes? How much electricity for all those nodes to do the sums to validate the blocks needed to handle that.

Whereas for Autonomi transactions the client on the user’s computer does nigh on all the work getting all the validation data collected and validated and then a few nodes only need to check the signatures are matching up and store the transactions. No need for massive sized nodes to do block validations

Anyhow as @southside says you have a huge job ahead of you to convince the dev team that block chain solution is superior to a digital transaction system which does not need a huge blockchain node system just to do a billion to 10 billion storage transactions a day.

Good luck with comparing it to old tech too.

5 Likes
18

Solana firedancer does 1 million tps. Blockchain is not the issue here

Concensus is not as easy as you state and there will be more required than ‘ANT native’ just being another data type

1 Like
19

At least 10 times too slow

How many nodes are needed. and when adding another 10 million tps needed.

At least with Autonomi it is the millions of clients doing most of the work and a small number of nodes required for each transaction. Even now with 15 million nodes and say 10 nodes needed (close nodes to transactions and 2nd set) then that is 1.5 million transactions being processed at the same time if evenly distributed, since data is random distribution then it’ll be close to even. But if billion transactions a day then there will be on the order of 200 to 1 billion nodes at least. With just 200 million nodes then its 20 million transactions possible at the same time, but with the more likely 500 million then 50 millions. Of course nodes can parallel process too. Damn thats real potential, but hey, block chain is so much better than this isn’t it.

You over state consensus and minimise what I said to “another data type”.

Guess we are done here. If you ignore the client doing most of the work rather than block chain nodes, and the network already having the nodes for the work. More data being stored the more nodes to handle the work load.

As I tried to say without continuing disagreements, you have a real hard job ahead of you to try. You have your heart set on using blockchain, so you lead the charge with the team. Do a github comment/issue so its “on the books” to be looked at

4 Likes
20

This network does not scale the way you portray. At least not to my theoretical understanding. You can always change my mind of course. For data, yes. That’s what brought me here and why i am happy experimenting.

What i think is that adding a payment layer will add complexity to a point where the network will face the same type of problems blockchains have. Payments cannot be double spend, and i have yet to find mathematical proof they wont be. I have looked into the intrinsics of the prior token design.

I am not ignoring clients doing most of the work, i’m saying it was irrelevant for this issue/discussion

1 Like