Community Token Proposal

[loziniak]

What I want to achieve

1. Autonomi token standard, that enables issuing own token by anyone – from scratch, or by wrapping existing ERC20 tokens. It does not have to become “native” yet, since it will have much utility anyway. Based on ideas by DavidMc0, Traktion, Riddim et al.
2. Rust library for token operations
3. Simple GUI wallet
4. Bridge smart contract to burn tokens on Arbitrum side, with option to updgrade for 2-way operation
5. Simple exchange scheme for different tokens

Work will be open sourced under GPL license.

How

• Carefully read and consider community suggestions.
• Comply to standards required by MaidSafe team, and their suggestions.
• Contact @dirvine on a regular basis to get advice and insight.
• Dig into sn_transfers crate code to familiarize with old Native Token design, payment proofs needed for data storage payments, DAG indexing/audit, etc.
• Consider extending a proposal to meet an RFC process requirements, but discuss if relying on it doesn’t make the project too dependant on MaidSafe’s infrastructure and thereby centralize it.
• Get inspired by ERC20 standard as an inspiration wherever applicable, to make the standard as familiar to newcomers as possible.
• Work will be openly coordinated by a project in safenetforum-community Github organization, together with the needed code repositories.
• Code will be tested and documented to comply with industry standards. This could be postponed if there is a risk of being late for deadlines set by Impossible Futures program.

How long will it take

Basic working functionality (proof of concept) seems possible to be achieved by May 6, an Impossible Futures deadline, assuming weekly workload of 20 hours. If not, the priorities will be as follows:

1. A token itself
2. One-way ERC20 token burn smart contract and bridge
3. Exchange or marketplace

The work will continue after POC deadline of Impossible Futures, on a regular basis as funds allow, regardless of a success in the program.

Costs, funding

I will work on a “pay-as-you-go” hourly basis, effectively using funds, that supporters transfered to my Arbitrum account: 0x708eEEC1126cC1Df9A7B60A890aD932360B6C46a. My rate is $35/hour, or equivalent in any token, that can be swapped to USDC on Arbitrum Uniswap.

Reporting, status

• Daily status: what I did yesterday, my plans for today, time spent, funds used/left
• Weekly: longer reports, roadmap updates

Impossible Futures

I intend to register the projet for Impossible Futures program. If I happen to win the prize, it will be divided proportionally among 20 biggest supporters, up to 150% of the support amount.

Example:

1. Supporter 1 transfers $6000
2. Supporter 2 transfers $1000
3. I work for 150 hours (used $5250)
4. I get a $15000 reward
5. Supporter 1 gets $9000 (6000 * 150%) back
6. Supporter 2 gets $1500 (1000 * 150%) back
7. Unused reward ($4500) and support ($1750) is left for later development

Other developers, the team

Other developers are invited to take part in the project. We will share potential rewards proportionally to hours worked. Everyone is encouraged to publish Arbitrum address and hourly rate (see “Costs, funding” section) to get funded as well.

Future (beyond POC)

• Enhance Bridge for 2-way operation, allowing conversion from Autonomi to Arb/ERC20.
• Implement as Native Token
• Modify Node software to accept NT as a payment and verify NT transactions.

Risks

• It can happen, that there will be little support for the project and I won’t be able to develop this in my spare time for free as well. This can happen at the beginning, also funds can end in the middle of development.
• It’s possible, that MaidSafe team will not support the project with their insight. This could mean node software modifications won’t be allowed and it will not reach the Native Token phase.
• MaidSafe can announce they are switching the focus to (native) tokens soon as well.

Unpredicted situations

In case of disagreement, decisions can be made by votes of supporters, verified by signatures, for examples through this service.

Questions

• Should we use Dev Forum for coordination, comments etc.? Here we gain visibility and possible support, but perhaps it’s better to not flood this place with community dev content?
• Is there a need for a non-development job, or developers can handle that as well? Here I mean project management etc.
• What could be the name for this token standard? ARC01? ARC20? ARC0062? RFCxx?

Reference

Native currency

The GraphEntry type is the foundation for that and was developed from the native currency we had. So it allows the same native currency we had to exist in the data form. I can try and help here where we we’re/are/going Where we were - Old Native Currency Used a thing like GraphEntry GraphEntry has the value component that can be `spent in the outputs we can check the outputs are non zero and sum to the value being spent. So that’s all there now, however it also had A genesis transaction t…

Native Autonomi tokens <> ERC20 2-way bridging ideas

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 b…

Transactions - a chained type to replace CRDT Registers

Just a wee note @happybeing but good to get your feedback. I have an internal discussion now on replacing registers and preparing for generic transactions. All logic will be client side for these, so hopefully max flexibility and better ease of use (no more understanding crdt trees and DAGs etc). I should say though app devs should still use one time use keys here to make this work better for them. As we use BLS there you can derive any key from a root key, so that becomes simple but efficient. …

New data types - summary and discussion

@dirvine, I’m glad to see progress on this. I’m not sure if my suggestion for changing the name of Transaction was considered (see “Transactions, the name” below)? Also good to see that filesystem APIs are being considered/worked on. I’ve been working on my own solutions for this (both library and app). It is important to get this and the other last minute APIs right, so I’m concerned this will - like registers - end up not being thought through in a rush to launch by end Jan. Perhaps this is…

Who am I

Hello. I am a freelance developer, in Safenet/Autonomi community for 9 years. I started to use Rust for a private project related to Autonomi 4 years ago. Since that time I even happened to make small contributions to Autonomi codebase (#18 on contributors list ). I also have experience in Ethereum/EVM, created a wallet, and a 2-way bridge with smart contracts.

• Github: loziniak (Maciej Łoziński) · GitHub
• LinkedIn: Maciej Lozinski - JAMSplayer | LinkedIn

[loziniak]

Any questions welcome Tomorrow I’ll start drafting a plan and maybe even some code.

[TylerAbeoJordan]

This is an interesting proposal. I would like to hear about potential utility for this token system, from you @loziniak and other community members.

Cheers

[happybeing]

Looks great. Maybe AGPL which is a little tighter than GPL?

Good luck!

[DavidMc0]

Apart from potentially clearing the path for Native ANT, to me the low-hanging fruit utility for this kind of system seems to be enabling:

1. DEXs on Autonomi (need the assets wrapped natively to be able to trade them)
2. L2 like scaling for any wrappable asset, with possibly near zero fees, and probable high privacy for transfers due to lack of blockchain for Automoni-native transactions

To be honest though, I can’t be sure what will be possible until it’s developed. Questions about what will work well remain, and exactly what can be achieved in terms of privacy & low-fee transactions ahead of Native ANT, I don’t know.

But, eventually DeFi / DEXs / ICOs / EVM L2s etc will all be possible on Autonomi, and this seems like a first step towards that kind of possibility.

Well worth supporting IMO.

[loziniak]

Hi! This is conceptually similar to ERC20 in Ethereum ecosystem – universal fungible token standard allowing for any utility, depending on application.

One simple example can be my recent usecase of erc20 token I’m issuing on Base network. A guy, who runs a drawing course, wants to add certain amount of the token to every course sold. He and his graduates have an imaginary sci-fi world, which they draw, and the token is a currency in that world. Also, students can buy private lessons with it.

[loziniak]

@happybeing

Looks great. Maybe AGPL which is a little tighter than GPL?

I’m not sure it would have any advantage… AGPL is about counting SaaS as distribution (hence forcing people who use the software for online services to provide source code). Until we modify node software, the code will be used client-side, so we’re cool. And even later, if someone makes modifications to nodes, I think they will open-source it anyway, because no one will use closed source nodes.

[happybeing]

There’s no disadvantage, but if someone uses your code remotely that’s correct covered too. I don’t see a problem there.

[loziniak]

Thanks, perhaps it’s not a bad idea. Just thinking about a saying “Don’t fix what does not need fixing”, that’s all.

[loziniak]

Hello.

I have great news. We are qualified to Impossible Futures program. $250 will be added to my funding pool address (edit) go back to supporters as a part of prize.

Also, a repo is created on GitHub:

GitHub - safenetforum-community/community-token: Autonomi token standard, that enables issuing own...

I’m adding daily updates in a GitHub Discussions topic

There is a GitHub project also for easily tracking the progress: Community Token · GitHub

[Nigel]

Congrats! Absolutely worthy submission.

[Profess]

Congratulations for taking on the task and the decision! This is a great project that will pave the way for a native token..

[blvd]

native token makes absolutely zero sense when there are cutting edge blockchains that scale pretty much infinately.

Some of them provide blocktimes which are already close to the theoretical mathematical bounderies of max transaction speed. Autonomi will not ever be able to compete with these transaction speeds, therefor DEFI on autonomi will not ever come to fruition at scale.

Integrate with those chains, don’t try to beat them. We are years and years behind, there is no need to re-invent the wheel here. Trying to keep up is the worst strategy.

Be smart and utilize their liquidity and network effect. We are a data network, not a currency network. Our data network perfectly integrates into those chains, and they perfectly integrate into our network.

[Profess]

April Fool’s Day was 1 April

Well, unless you are writing seriously… Then explain how it is possible that some blockchain, which is inherently a deterministic network, can be faster than Autonomi, which is a probablistic network - using the same computing power, of course, and with the same energy consumption in both cases?

[blvd]

I meant to say as close to the speed of what’s theoretically possible when it comes to a blockchain.

Now, once you implement a DAG (which is what autonomi is planning to implement when it comes to its native token), i do not believe it will scale very well when it comes to transaction speed specifically, combined with its close group node design.

Sure, Autonomi may very well be capable of doing a billion transactions per second one day, but will it be capable of transacting in miliseconds such as some blockchain do (n=1 start to finish)?
I don’t think so, there are too many theoretical limitations in our architecture.

I look forward to Autonomi proving me wrong though :- )

[Traktion]

@blvd

Now, once you implement a DAG (which is what autonomi is planning to implement when it comes to its native token), i do not believe it will scale very well when it comes to transaction speed specifically, combined with its close group node design.

Having a close group look after an element in graph is a great way to quickly make changes to just that element. The smaller the number of validators, the better, as far performance goes.

You need to be more precise in your argument than just presenting FUD.

[blvd]

For example, its an open network, allowing suboptimal hardware and isp

[Profess]

@blvd

but will it be capable of transacting in miliseconds such as some blockchain do (n=1 start to finish)?

Can you be more specific about this? Are you talking about on-chain or off-chain transactions e.g. on a peer or L2 network? What proven in-use blockchain network achieves the speeds you write about?

[blvd]

Just a simple layer 1 transaction
Sonic transactions have finality of 720ms
Sui 400ms

[Traktion]

@blvd

For example, its an open network, allowing suboptimal hardware and isp

Who would want to use a closed network for a distributed payment system? You may as well just use Visa and be done with it.

If the hardware is good enough to support distributed apps and their data, it is going to be good enough to allow the storage of a few bytes for financial transactions too.