RFC 0061 — Safe Network Token Distribution

Autonomi Network Token (incl (e)MAID)
,
82

The 9 decimals comes from efficient use of u64 integer.

2^32 SNT is 10 digits. Nine decimals means then that is 19 digits.
A u64 has 19 1/2 digits (the 1/2 is part use of the 20th digit). So then using 9 decimals is maximising the use of the u64 variable.

u96 gives 28 1/2 digits which would allow 18 decimals.
u128 gives 38 1/2 digits which would allows 28 decimals

Granted that is correct, although Safe has the better chance since its all in the DBCs

If the version is built in up front then the installed software base can recognise the difference. It is not a reason to say we only keep the original.

Personally I would like to see u128 implemented from the start even though 28 decimals is too much for reasonable use for the forseeable future. But personally, and I argued this last time, 9 decimals is building in a limit that is short sighted. 18 decimals would be far better and 28 while not likely to be usefully for decades will not be an issue.

But I can see that to go above 9 decimals at this stage is to invite spamming using 1 x 10^-28 dust. But with all the work the client has to do to split a DBC and send it, may mitigate this issue where sending dust will cost the spammer more than actually spam.

One way to implement 9 decimals now and increase later is to use a u128, but the core code will not approve a DBC with more than 9 decimals. Then during an upgrade the node software can then increase the number of decimals to say 12, and next time to 15, etc. Since Nodes have to upgrade within a reasonable period (ie only be a couple of versions behind). And the enable point/trigger is worked into the upgrade which occurs after the time all nodes will have had to install to still be allowed on the network.

@JimCollinson I consider hard setting the decimals to 9 places will sorely limit usefulness of micro payments since the perception (& hope of many) that SNT will rise to 1000$ or more and thus 1x10^-9 is at the limit of a micro $ payment. Even 12 decimals will cover this even if/when SNT is worth a lot more in 20 years.

I suggest that DBCs use u128 (allows 28 decimals) even though we would not want 28 decimal places, but this would then provide a simple path, through code upgrades, to increase the allowed decimal places from the original 9 over time as its needed and/or compute power/net-speeds is higher.

Basically there is 28 decimals from the start but the last 19 places have to be zeros while decimals is limited to 9

11 Likes
83

In this case, airdrop is more of a regulator term of art, rather than mechanism/process.

I’m not quite sure I understand where your KYC worries come from? None of the proposed distribution of Remaining Tokens, or MaidSafeCoin funds etc should require that.

That is correct. Hence the increase to maintain a 1:1 conversion.

6 Likes
84

:wink: … not if we have a transaction fee.

85

Transaction fee of 1x10-9.
SNT at current sort of prices - choose high $1.00
1 SNT ==> 1,000,000,000 transactions.

Yea, transaction fees will not stop spamming billions of transactions.

Transaction fee at a very high value of 1x10-6

Yea for a mere 1000$ you get a billion transactions and destroy micro transactions in the process since half the micro transaction is in fees. Spend 2 x 10-6 to tip 1x10-6

Nope with nine places reasonable fees that allow micro transactions will not stop spamming.

This is one reason why the concept has always been for no fees, change the world, especially in places where 1 cents is worth something.

86

Thanks for all the discussion folks. There is a lot to respond to here, so I think I’ll start with making some observations on the larger themes, and then make some subsequent posts to cover more:

On Automation of Network Royalty Distribution…

First thing to note here is that the automation discussed isn’t “the automated distribution of Foundation funds” it’s the Network distributing them directly without them touching the Foundation at all.

We are specifically looking at ways we could make this kind of automated distribution of funds ready as part of the launch candidate. But at the same time please don’t underestimate the size and complexity of this work, particularly for App Developer Rewards.

If you are advocating that the launch of the Network should be delayed until this automation is in place, then you may have to accept the possibility of an indefinite delay; because like it or not, we have a finite runway.

But we are specifically providing for this kind of scenario in the RFC, which allows us to get the Network up on its feet, sustaining itself, and then continue to work on these key features. Note here, that this is also the scenario envisaged by the original project white paper, because it is a significant task, and therefore was originally slated as coming post-launch.

On Automated Distribution of the Remaining Tokens…

We also provide for the scenario where things like the automated distribution of the Remaining Tokens to users are subsequently deemed too technically challenging, or inadequately secure, with a backstop that would have them airdropped MaidSafeCoin holders and investors, in-line with what many are suggesting.

This outcome isn’t the first choice as it has it’s own significant drawbacks, and it doesn’t align with the original prospectus:

Namely, distributing the entire supply to a small group of people, maybe only a few thousand, is still a significant concentration of power in the hands of a few. Far better aim to distribute these funds among users of the Network, through the process of it being used. It’s far more inline with the ethos and aims of the project.

But… as a backstop, we’ve conceded, it’s a pragmatic solution, and limits the even higher concentration of resources at the Foundation, hence the reason we have provided for this backstop in the RFC.

On Core Developer Rewards…

Likewise, calling for things like core developer rewards—part of the original promise described in the Safecoin white paper—to be removed from this package is eliminating the proposed ongoing funding of the Network development which would include things like automated distribution of funds, etc.

So please think carefully before you dismiss the idea of Core Developer rewards, as it’s a tenet of the sustainable ongoing development of the Network, and one of the few areas where automated distribution of funds is likely to be unworkable, and thus will require oversight by the Foundation.

12 Likes
87

Not sure how technically feasible this idea is going to be but her goes. Is there any way to reward the first ‘x’ amount of safes started that have provided ‘x’ amount of resources for ‘x’ amount of days/weeks? Could work as a good marketing campaign and help with the distribution of the tokens.

5 Likes
88

We are looking at solutions where there is a curve to pay out at a higher rate in the early days of the Network, and then level out as it grows. And in particular rewarding those who are contributing to the Network in the form of storing data and/or contributing resources.

As you point out this could be both a good mechanism for equitable distribution of the remaining supply, and also serve the Network well in terms of early adoption.

10 Likes
89

I guess as usual I’m using Tezos foundation as precedent. No one had to KYC when participating in the crowd sale but the Swiss foundation upon network launch required it.

2 Likes
90

As far as we can tell at the moment, it shouldn’t be needed for MaidSafeCoin holders to get their SNT via the airdrop.

9 Likes
91

Early adoption could be a curse if cost of upload goes through the roof when subsidy really declines, people upload less, & network has to raise storage cost dramatically to keep farmers happy … all of which could trigger a spiraling collapse wherein price to upload keeps going higher and consequently fewer and fewer actually upload … death spiral.

This has happened many times now in crypto - it’s a financial reality.

SN needs to have a resilient economy and this is the opposite approach.

SN needs to be GREAT ENOUGH to attract people to use it WITHOUT initial subsidies.

SN is NOT Bitcoin and the same methodology for distribution is a fundamental error in thinking IMO.

2 Likes
92

It’s a blank slate at the moment, and I’m sure it will be subject to many discussions and options. Flat vs curve, various rates of release etc. Nothing is set in stone.

But it’s worth remembering that, as you point out, we are not primarily a crypto currency project, and resilience is the name of the game.

8 Likes
93

I think we need to talk about this kind of dichotomy in response to this RFC:

vs

On the whole the RFC tends toward staying true to the original project white paper and what it proposed to investors, ICO participants, and MaidSafeCoin holders within the current context.

Whereas some of the alternative proposals in the thread really tear it all up; some to a lesser degree, some to a coach and horses degree.

Minor changes to my mind would be things like the decimal point placement as @danda is pushing for. It has little bearing on the functionality of things, so yeah, perhaps we should be open to that? But at the same time it might feel like a significant shift to MaidSafeCoin holders to move from the 1:1 redemption they’d been promised, to now it being a 1:2,328,306,437 swap. Perhaps it is worth the effort pain and time to explain, and walk people through all that, or maybe it’s an unnecessary distraction?

But then there are others that are really more significant indeed, such as the entire supply being airdropped to MAID/eMAID holders ahead of launch (which is a very dramatic shift indeed with significant consequences), or those that effectively end the possibility of core developer rewards etc.

These are dramatic shifts late in the game, what are supporters, and investors, and holders (and yes financial regulators too) to make of them?

4 Likes
94

I’m not certain of the various items here, but late in the game for whom? As I’ve already mentioned in this thread, many of these ideas have been debated here for years. That the team is only now paying attention to it … well what can I say really. Finger pointing isn’t going to help here, so IMO, break things down and tackle them one at a time as quickly as possible in new focus threads.

Otherwise, it’s again as I said earlier, what’s the point of this discussion if the team isn’t really open to hearing options and making changes. I’m certain we all have better things we can be doing if this discussion is just for show (which I really want to believe that it isn’t).

1 Like
95

I don’t think this, nor your other comment earlier, is particularly fair nor constructive.

There are many aspects that have been debated for 8 years. Thousands of threads, tens of thousands of discussion points, often with out any particular conclusion to hang a hat on, often circular and polarised. All of which are digested by the team.

The RFC process is an opportunity to actually dial in to a conclusion. If you’d like a specific aspect changed, then let’s discuss it.

It’s late in the game in that we are approaching a launch, and we now have to put plans before a regulator so we can actually be in a position to issue the token, let people have their return on investment, have the ability to access the services of the Network via MaidSafeCoin, and build a viable and resilient Network.

Now is the time to dial it in. I’m not sure how that is finger pointing.

4 Likes
96

And often too, just the opposite. There is more than one thread that has polls that lead to clear conclusions.

No point debating that though - you must be aware of it if:

I asked some questions in my first post in this thread which weren’t even answered. Kinda not very inspiring to go further for someone who wants to discuss it … is it?

I get that … and I don’t want to point fingers (I wasn’t accusing you or the team of pointing fingers - I was saying that I didn’t want to point them), but, since we are here I’ll just say it: The team could have been nailing all this down years ago … where was the leadership when the runway was long? Do you understand the frustration here or am I just not reaching you?

2 Likes
97

Do you mean these questions?

They are the only questions I could pick out, and they are essentially the same question, right?

The are really already answered by the RFC: there will be no time cost in getting us to launch because we provide for a solution that enables us to launch when the Network is ready, while we continue to assess the viability of those additional features, and yet still have a fallback to a distribution to MaidSafeCoin holders and investors should they be considered non-viable.

2 Likes
98

Cool … I was getting a hint that such was the case by your other comments. I didn’t see it in the OP though … maybe I was supposed to be reading somewhere else or maybe I just missed it. Being ignored though wasn’t helping.

So, if you don’t mind humoring me a bit more for clarity, as regards to the distribution, all beyond the 1:1 of current holders will be kept by the foundation until the mechanism is implemented? So the 1:1 conversion is everything for the network to run on until things are solved.

But the problem here and now is that the regulators want to know in advance how it will be solved … before it is solved?

Did I get that correct?

If so, then I’d still go back to:

In a couple of weeks, with polls, we could have decent perspective and debate on each point of the potential solution.

Edit: sorry, but for clarity I mean the regulators want to know how it will be solved before it is implemented (so a solution is required at launch, even if it isn’t fully implemented?) – If I am making sense.

99

When you say 1:1, I’m presuming you are talking about the MaidSafeCoin holders share of the supply? (sorry that label has been applied to various things in this thread.) The breakdown, of the Total Supply created at Genesis is as follows:

  • 10% to MaidSafeCoin holders via airdrop
  • 5% to Shareholders paid out by the Foundation over a year in 3 tranches
  • 15% to the Network Royalties pool to begin paying out Developer Rewards etc
  • 70% to either be:
    • Distributed by the Network itself if this is viable prior to launch
    • Or held by the Foundation until this feature is complete, then distributed via the Network
    • Or if this is deemed no longer viable or too risky etc then distributed to MaidSafeCoin holders and Investors in the same proportion as the original split.

Yes effectively, we need to lay it out to them prior to launch how and where and to whom these tokens will be distributed so we can get a ruling in order to have the legal vehicle to issue the tokens. These things take several months to work through.

4 Likes
100

cool, I appreciate that point. The reason I keep going back to breaking things down and having more threads and such is that we can have specific debate and polls. I think this is important for the community to come to agreement on things.

In the past these polls were all community driven and the options wouldn’t have necessarily been in accordance with the limits of the team or the law, so it would be best if these were created and run by the team (or probably by you I suppose as you seem to be taking lead here).

I don’t want people to have sour feelings about rushed decisions. So having polls and encouraging participation would bring community support here. Not sure I can say anything more without repeating myself. I believe this is really important.

4 Likes
101

I’ll just say I’m now against giving all of supply to holders/addresses of MAID/eMAID.

I am in favor of the RFC in its current form almost 100% with the caveat that I do like @danda’s idea on putting the arbitrary decimal ‘satoshi standard’ in crypto to the wayside.

So RFC effectively has my support. FWIW.

7 Likes