RFC 0061 — Safe Network Token Distribution

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

@oeytng Thank you for your articulate and insightful response. I’d like to offer a more detailed analysis than my “back of a napkin”/“back of the envelope” list quickly hashed out before.

The biggest issue I’ve had with this RFC is the seemingly haphazard way that the initial allocations were reformulated, the way “royalties” were described (horrible term) compared to “developer rewards” or “developer pool”, and what appears to be a vast increase in the role and power wielded by a foundation. I thought to myself, “Have a few years worth of forum discussions made me think that SAFE is something it was never intended to be?” In light of the current RFC I picked through the original whitepaper again to see if I had missed something before. There were a lot of good ideas in that original whitepaper! But there were also stipulations, uncertainties, and some vague aspects that were good to refresh myself with. Here are a few things I’d like to highlight from the original whitepaper:

0) A new internet and a foundation to promote it.

" This project is simply the beginning of a new Internet, one that we all own and nobody controls, this is the “Internet sans frontieres!” The MaidSafe Foundation will be a key player in this proposal and exists to ensure fair distribution of wealth, while helping to foster education and innovation."

A new internet, hurrah - but the foundation role should be no surprise as a potential fly in the ointment if not given the proper role… It’s been part of the picture since day one. Thinking back, I suppose this was less of a concern the first time I read the whitepaper, thinking at the time that the charity/foundation’s role of was smaller, and seeing that it had rather noble intentions compared to other offerings in the crypto space. Recent discussions have somewhat indicated the opposite, increasing foundation roles/power in a way that weakens the network. So there was a disconnect here when considering RFC0061 that leaves a bad taste.

1) Total Safecoin (aka SNT) to be issued will not exceed 2^32

"This paper demonstrates the creation of a fixed number of coins over time 2^32 (~4 billion), which can be further subdivided to facilitate trading. "

“Safecoin issuance will be capped at 2^32 (4.3 billion)…”
“The data structure of such can be illustrated as … The fifth part indicates the level of subdivision of the original token, i.e. it contains the value of x. This format allows the tokens to be split into 2^248 parts if required.”

There it is, stated at least two times. The safe network will have a 2^32 hardcap, period, period. Some level of divisibility was intended up to a max of 2^248. There could be less tokens available due to burning or loss, but never more than 2^32. This is something that the current RFC has violated and should be corrected.

“The crowd sale will enable a direct purchase up to ten percent of MaidSafeCoin. These crowd sale participants will be buying MaidSafeCoin, an intermediary coin that will be swapped on a 1:1 ratio for safecoin once the full SAFE network is launched.”

Opps, technical error happened and a few more than 10% were sold. That’s not the fault of the participants. That also doesn’t mean you can change the hardcap willy nilly. The hardcap and the 1:1 exchange takes precedence, and the % is recalculated based on the amount sold relative to 2^32 total coins.

2) Initial allocation of SNT, “Day 1 Injection” ie. Genesis Tokens.

MaidSafe will allocate 30% of the tokens on day 1.
Up to 10% will be available for purchase via the crowd sale, 5% for the existing MaidSafe investors, 5% for the SAFE core development team and 10% for the general developer pool.

So here were the promised outlays. This equates to the following amounts:

  • MaidSafe Shareholdings/Investors = 214,748,365
  • Core Safe Network Development Team = 214,748,365
  • MaidSafeCoin = 429,496,730
  • Developer Pool = 429,496,730
  • Total Remaining implicitly available for Resources Rewards = 3006477106

2a) The conundrum

So now we deal with “the conundrum.” A technical error occurred during MaidSafe’s crowdsale and a total of supply of MaidSafeCoin is now 452,552,412. That is a difference of 23055682 tokens, which is only about 0.537% of the 2^32 hardcap. It really doesn’t make any sense to even consider changing the hardcap**, and the remaing ratios relative to the hardcap, or divisility etc., to adjust for the glitch in the manner that was proposed in this RFC0061! - full stop.

@JimCollinson, @dirvine - The simplest solution here is that instead of exactly 30% of the coins being allocated on day 1, there will actually be approximately 30.537% allocated. This does not change percentage of total token supply promised to core developers and non-core developers, nor does it change what was promised to MaidSafe investors. There was never a promise that ALL remaining tokens would be issued to farmers, just that there would be a hard cap of 2^32. KISS. Problem solved.

3) Developer rewards

“15% of all safecoin earned will be allocated to the developer pool. This will ensure the developer community is highly motivated and rewarded for providing free-to-use applications”

“It is possible that 10% of these coins maybe recycled if a an idea of automated developer awards comes to fruition.”

“5% of the developer pool coins will be given to the core developement team.”

Here is a detail I overlooked before. The core development team will not get 5% of total earnings/farming rewards issued. Instead it’s 5% of the 15% set for the developer pool = 0.75%. If we review the math, that means there is a missing 4.75% of earnings in the developer pool are free to be used for something else. Is this where Pt* comes in? Is this just an administration or “governance” fee taken by the foundation? That’s a quite large administration fee, yikes! There is too much left to the imagination here, the vague wording needs to be corrected.

4) The role of a foundation

The MaidSafe Foundation will initially:
• Hold and distribute safecoin for developer pools
• Manage issuance of MaidSafeCoin to funders and existing investors
• Hold all patents and use safecoin to pay for the upkeep and further patents for all projects (until this sphere cannot be litigated against, the MaidSafe Foundation will act as the holder of defensive patents, of which there is already a considerable worldwide portfolio, to protect the decentralised Internet).
• House the MaidSafe team in an HQ and provide funding for independent development pods, worldwide
• Provide finances for the core team and development pods for a period of at least three years

No further actions can be taken by the Foundation, unless the authority is requested by the community to add additional objectives to this list

The original plan for the foundation specified interesting roles. Can the community ask that the foundation have certain objectives removed?

Presumably the MaidSafe Foundation roles will be dissolved or absorbed by the Safe Network Foundation. What’s not clear in the original proposal is how the foundation will be funded (by private donations or through implied administration fees taken in SNT). Up to now I had always presumed that the foundation finances would not be mingled with the developer pools in any way and it would be funded through donations just like any other foundation. That would be a preferred approach. Non-profit foundations usually rely on endowments, and donations. This is better than network “royalties”. The Bamboo Garden fund is a good example of how the foundation would likely receive large donations that could be made part of an endowment to fund operating costs.

This group will ensure the correctness of the coin issuance and also that every project that is applicable is included in the polling system for funding of that project. The board can put forward their suggestions and conclusions for any funding for projects. The assurance of developer rewards will also be continuously-monitored and managed. This mandate will be kept as minimal as possible to prevent unfair or ill considered decision making.

So yeah, perhaps willfull blindness on my part when I read this the first time. MaidSafe was transparent in their original intention to use a foundation and a board to manage the developer rewards. This is a very practical approach for just getting the network launched, but imo it is not ideal long term and adds a huge attack surface to the network. It would be better if that function could be eliminated. Imo instead of having only a goal of partial automated reward disbursal from the developer pool, all rewards would be automated. This may not be possible for core developer rewards, but the goal should be to minimize the role of the foundation in token distribution after the initial genesis supply is introduced. If there is also a way to eliminate the need for it to issue genesis tokens, all the better. This leaves the foundation to pursue other aims related to educational outreach, hackathons, developer outreach, marketing, patent and trademark protection, legal issues, fund lobbyists, normal non-profit corporate activities and all the “human” related aspirations, benevolence, malevolence, and deficiencies that go along with that, that are by design not directly tied to network functions in any way. This functional partition between in-network and out-of-network roles is important to long term success imo.

7 Likes
163

My perspective is that launch should either be with the end-state upfront or control of anything not core-dev should be decentralized into the hands of the community, and allowances should be made for consensus-based updates to the network so that any dev can have their contribution accepted/rejected by the nodes directly. Otherwise it’s just a centralized system promising to eventually be decentralized at some unknown, unclear “end-state”.

A recent report by Trail of Bits sponsored by DARPA point to the kind of centralization problems holding back lots of supposed decentralized networks: https://assets-global.website-files.com/5fd11235b3950c2c1a3b6df4/62af6c641a672b3329b9a480_Unintended_Centralities_in_Distributed_Ledgers.pdf

A snippet:

“We show that a subset of participants can garner undue, centralized control over the entire system:
While the encryption used within cryptocurrencies is for all intents and purposes secure, it does not guarantee security, as touted by proponents.”

Safe network should not start with such a glaring weakness.

Another thing is that the discussion isn’t very MECE in general. For instance, if governance and distribution could truly be separated where governance of the safe network is truly in the hands of node operators and other participants while token distribution was still “centralized” with the foundation/maidsafe, I could support such a setup. But it’s hard to achieve such a separation because, even if a system were to be setup where each participating node gets one vote, initial entry onto the network as a node still ultimately depends on control over tokens (i.e., need for capacity and tokens are required to fill the network to create the need for capacity and therefore nodes). There’s more, but let’s focus on that key factor alone for now.

So token distribution ends up being a governance distribution as well. And given the ultimately economic security model of the system (again, tokens required to create need for nodes), more than 33% of the circulating token supply should never be controlled by a single entity at any one time as the current RFC proposes.

1 Like
164

It’s interesting to read these last few replies. Some great points and dialogue.

I personally don’t have much a problem with foundations or hybrid systems as they tend to be compromises that allow things to accelerate within existing systems or legal structures but I do see pure decentralization as the end goal or holy grail if you will.

I’ve witnessed issues the Tezos Foundation had with an early board member that then went on to vote out and become highly effective in its goals.

OTOH Ethereum has constantly been criticized by bitcoin maxis and others in the crypto sphere for being under such centralized dictatorship via its foundation and Vitalik.

I think @Bogard is correct that we should probably be hearing some from Heather. Tagging @Heather_Burns its always great to hear from you btw, great addition and role filled @maidsafe.

Jim’s expanded role is a lot of responsibility too so I don’t pretend that every piece of input we have is at the top of the list compared to jumping all legal hurdles in the final miles of launch. Which we are all desperate for.

Yet, this is an RFC, these things should be hashed out and perfected first go around, and what is any decentralized project without a strong and mindful community?

Just commentary here as I’m not as technical as others but I do hope being an RFC, that hashed out and published proposals stand a chance of a fair trial.

Again, satisfied with the initial proposal but also open to this increasingly interesting developing discussion.

13 Likes
165

Just to clear up what seems to be some confusion around my role - my work is on the regulatory affairs/policy/politics governance side, as well as on the project governance side e.g. the structure of the OSS project itself. Token governance is an entirely different discipline, issue, and set of expertise; it’s actually unfortunate that it’s even called “governance” as it causes a lot of conflation of apples and oranges, in the public sphere as well as in community perceptions of what my role involves.

I’m currently doing my best to support Jim on these ideas as they’re fleshed out, with an eye on what sort of secondary issues they could create elsewhere e.g. crossover regulatory issues. Andrew, who’s the financial/crypto/numbers mind on our team, is also supporting on those aspects.

Jim is now off on a well-deserved break with family, but we’ll be picking this up when he returns refreshed.

(BTW, the speculative fiction post I wrote was not about this project, if that wasn’t obvious; it was a very specific dig at a very specific project which has defiantly refused to address any of its corporate control or project governance issues, at all.)

16 Likes
166

Thanks for clearing that all up @Heather_Burns. :slightly_smiling_face:

8 Likes
167

Regarding the automated rewards system, I feel there’s two parts to it.

  1. The decision process to make a list of reward payments

    a. who to send payments to (ie the address, not the individual/company)
    b. how much to send
    c. when to send

  2. The sending of payments in that list

    a. proven consensus the reward list is correct (managing conflicts due to mistakes, disagreements or race conditions)
    b. creating the signature for the payment, probably requires coordination (which is a kind of consensus?)
    c. ensuring the transactions are successfully broadcast
    d. permanently storing this round of rewards for future reference

This process of ‘make a list then send payments’ runs in a loop, responding to changes in network usage.

We can definitely work on the first part right now. How should we make the list? That list-making process will be relatively automated by necessity since the process needs to be accessible; it can’t be an opaque team of people making lists without accountability. The list making and checking process needs a certain degree of logic and an api and broadcasting and auditability regardless of the way the sending in step 2 is done. We can design it now. How should we make the list of rewards? What’s your thoughts?

In some ways the RFC tries to put some guidelines on the list-making (mostly who they go to) but I feel we can start to flesh this part out a lot more, especially the techniques for automating it. Regardless if the sending in step 2 is a foundation process or a network automated one, we still need the same kind of list making.

The second part is more subject to politics and subjectivity, especially the consensus step. Hopefully we can design a manual human process in a way that doesn’t block us from automating it later (or even informs and improves the automation). What sort of blockers are likely to be encountered? What currently makes automated payment difficult? I’d guess probably the consensus part, agreeing what the list is.

I feel like people are getting hung up on the idea that ‘people are in the middle’ when actually those people probably don’t want to be in that role making impossible decisions. Let’s try to design a way to make the foundation job and the community job as easy as possible and in a way that supports each other rather than assuming people will make it go badly and we can only rely on rigid algorithms.

Let’s design the algorithms, but with the necessary flexibility (no more no less).

20 Likes
168

Could not agree more and also add, let’s force simplicity in those algorithms. There are ideas discussed in-house, it’s time they were all out and get every head into them?

12 Likes
169

I appreciate the clarification

4 Likes
170

There is an easier and tax-exempt way to deal with the 70% if the goal is to transfer the value to the current MAID holders and investors. Simply burn the tokens. It sounds like a gimmick, but it accomplishes the same thing as distributing them to the holders at any given time, but is not subject to tax. It is like a stock buy-back instead of a dividend and uses deflation to increase the value of the tokens in circulation at any given time. And it could be easily automated.

The only issue I could see is that any tokens slated to be burned are not actually in circulation and therefore don’t really “exist”. So whether they are burned or not becomes irrelevant. Which gets to the next point: if the goal is to distribute to the holders and investors just do it by never creating the 70% of tokens in the first place. I happen to be in agreement with the argument above / related thread that you really don’t need to distribute the extra tokens over time. If the concern is whales holding they are more likely to do that if there are future pay days coming based on holdings. And if the concern is a few of them dumping tokens, well they can do that now, or can do that later anyway regardless of how many they have. It is the percent of market share that matters.

I get the idea that the 70% is supposed to be “seed tokens” to get the network going in the event that holders hold too tightly. But maybe the issue is that 70% is way too large an amount for that. Maybe put 10-20% aside for that and let the foundation handle it. The foundation could even have a charter to burn unused tokens from this pool after 10 years or something. And just never create the other 50-60% thereby preserving the value for the holders at the time the network launches. I knew the rules when I purchased some MAID, but I always felt that MAID holders only having 10% of the network value seemed low. Cutting the number of tokens by 2X to 3X seems to make sense making the MAID value 20%-30% of the Safe Network value.

This is intended to be a kind of compromise proposal that balances the various risks and concerns that have been expressed. I don’t know that we need an either-or solution.

2 Likes
171

Of course the slow release has virtually no tax implication.

  • spread across many more people
  • spread across many more years
  • and you’re earning them by farming

Would expect it to be only a % increase over normal farming, maybe 10%

Also with the very few who have MAID, there was a list of addresses with (e)MAID and its in the thousands and we know people have multiple addresses used to hold MAID. But spread it across many years then that number will rise to 10’s or more likely 100’s thousands if the network is a success.

This means the 70% has succeeded in encouraging more people to farm which also enables more people to upload which encourages adoption of the network.

The one negative I can see is the markets.
If markets know that the 70% is still to come then the price will act differently to the market realising MAID at 10% of total supply to MAID being 33 1/3 % of total supply might see an immediate price rise in SNT before all the exchanges to SNT are done. This could actually cause a significant price change from MAID exchanged to SNT which is a taxable event in many places.

Distribute the 100% at same ratio as RFC would in my opinion cause the market to value 1 MAID at the same price as x SNT given for 1 MAID

2 Likes
172

While I think this idea is a good one overall and am not against it. The markets will cause this to not be so tax-exempt as you might think. Without those future 70% it may (and only may - who can predict!) cause the price of the existing tokens to go up in value dramatically as there would then only be a fixed supply … and if they go up in price (at launch) much more than would be the case with the 70% additional tokens, then your tax implications at launch might be worse than with the 70% – assuming you want to sell them.

Of course that’s just my own FUD there … I can admit that. But based on market logic - which doesn’t always hold true.

1 Like
173

I don’t see that as affecting taxation though I understand what you are saying.

The point is that it is up to the person when they sell and how much they sell. So while if they sold everything, or the same number of tokens, tax would be higher it is a choice how much to sell and when.

If the tokens are worth more, you would presumably choose to sell fewer, certainly if you wanted to keep your tax liability down at the time. Your just have more left for the future.

4 Likes
174

For me, the goal is to distribute the tokens as widely and fairly as possible. Anyone that wishes to participate in the network should be able to earn them, without asking permission, in proportion to the benefit they provide the network. This helps drive adoption, capacity, community, value, etc.

Transferring all to “current MAID holders and investors” sounds like Ripple to me. A massive pre-mine. Basically, it is antithetical to my understanding of what makes a good cryptocurrency.

7 Likes
175

Is there a way to distribute the 70% to holders/investors on the condition that they donate x% to the foundation? I know this opens up a lot more questions just thinking out loud.

176

Yes, just give everyone their share - x% and transfer whats left to the Foundation :slight_smile:

But I dont see this as a popular solution. x% of the 70% is still a hefty chunk to leave the Foundation responsible for.

2 Likes
177

If I understand correctly, farming and rewards will happen unimpeded. The only question is how much extra subsidy/bonus to provide early on to foster growth and who administers it. At this time there is a notional plan for the foundation to hold and then release over time 70% of market cap for this purpose. Current MAID holders could have their tokens diluted 10 to 1 by the creation of the full market cap of tokens at launch (this was always a theoretical possibility, but now part of the plan). Hopefully the value of the network (market cap) will go up by more than that quickly to offset this dilution. I would expect that it would. My only point was that if there is a concern that 70% is too high for whatever reason (dilution, foundation holding, taxes) one easy way to distribute the value of whatever portion doesn’t want to be sent to the foundation is to just not create those tokens in the first place (or burn them).

EDIT: Other concepts that release the 70% slowly over time like a “lock box” or legally binding framework that the foundation follows, or some other method would also avoid instant dilution. I didn’t mean to imply we are on a path to 10:1 dilution at launch as I realize a lot of effort is going into dealing with just that issue fairly.

4 Likes
178

Well when the MAID tokens were released it was under the understanding that they represent 10% of total supply of SNT (safecoin back then) so the eventual “dilution” was known and people accepted that.

The thinking would be that the value of SNT will rise faster than any release of the held “pool” of 85%. Now 70% held since 15% is going to the foundation in advance to release to developers of core code and applications and maybe providers of sorts.

To release all at once or make the 30% the full supply (ie make it 100% of SNT) is a change to that and something the markets did not factor into the price of (e)MAID. And potentially see massive swings during exchange (e)MAID->SNT, Even a possible tax rulings in some places that its no longer a simple (or straight) exchange of name but different assets and taxable event. IE tax them on “exchange pricing - buy MAID price”

No FUD here just expressing what some real possibilities are and burying head in sand does not make them go away.

2 Likes
179

“Premine” doesn’t apply in that way to SAFENetwork. There is no “premining” in SAFENetwork.

Tokens going this way or that way on launch doesn’t affect it.
“Mining” in SAFENetwork is the farming, which happens by staying online and handling chunks. It never ends. Doesn’t matter if you give 100% or x% of the remaining tokens to one or 100 or everyone at start - whether via extra zeros or burning. Farming is the same, everyone running a node still earns, as paying for a chunk still must happen - and the payment size (value) will adjust to demand and supply for storage (thus connect to the fiat value as nodes respond by going on or off). And that is the “mining” of SAFENetwork.

Whether the initial tokens sit with maid holders, the foundation, lockboxes, or something else, is just determining which intermediate the tokens have on their way to distribution out among the masses.
Is it distributed via sell orders as network grows (price goes up), via foundation according to some rules, or via lockboxes according to hashing power, etc.

9 Likes
180

It would have a huge impact on the velocity of distribution and so initial growth rate of the network. I would consider this an extreme: 100% to existing Maid holders who quickly meet their immediate data storage needs and if most then collectively decide to hold on to their SNT for higher prices (a reasonable outcome to expect) would mean very low velocity of distribution. Non-SNT holders trying to farm some would then be sitting there with very little incoming data to farm. It may never end but with very slow farming rate the network will have an extremely low growth rate to its potential and be at risk to a fork that can more successfully distribute tokens to a wide audience that require data storage.

Part of a possible solution: The X-70% that goes to the foundation who then start paying for public service data to the stored on the network on a calculated “storage schedule”. Public domain books, videos, useful human knowledge and the like. Perhaps even democratise the process and allow people to vote on what should be stored next and maybe even at what rate. If the whole process can be decentralised it would be almost ideal. This would allow a much wider circulation of the initial SNT to everyone and anyone willing to become a farmer and avoid the extreme mentioned in first paragraph, kick starting the economy more efficiently.

Food for thought: What happens after the initial growth stage perhaps in a decade or so when there is a(nother) economic recession, SNT has clumped and pooled to few hands as money always does? We are back at the extreme mentioned in first paragraph. How can SN stimulate the economy again without reserves or ability to create more? A possible solution would be for that 70% to have a ultra-long view for distribution. Yet another reason to try really hard to make it decentralised.

3 Likes
181

It’s a very extreme and non-likely case.
First of all: all of them quickly meeting all their immediate storage needs, is very unlikely, but most importantly it disregards from the fact that data is produced all the time. Generally, more storage is continuously needed by everyone all the time - which is always growing and dwarfing any previously stored data. The bulk is not in the past, it’s always ahead.
Second - and also most important: 100% of the remaining tokens, still means the 70% of total supply. The holders holding on means the rest of the 30% are all the tokens in circulation, and that’s reflected in value. You are talking of velocity of token distribution. The velocity of value distribution won’t be touched by that.
The bulk of users (with the bulk of data) is also ahead in time, and they will buy from those 30% to upload their data. The competition will reflect in fiat value, and thus lower token velocity to node operators is still reflecting the same fiat value. (Also, as that fiat value increases, those hodlers will loosen up their grips => increased token distribution velocity as well.).

So I say the scenario/conclusions you describe, that node operators would not get data or paid, are not correct.

I.E.: as long as there are a fair bunch of tokens out there (and there will be), it is storage demand that governs value distribution. It requires a shortage of tokens so extreme that individual users cannot get hold of enough sub-units to cover individual upload acts (they need at least 1 per desired min cost upload). At that point, yes, the value distribution velocity is hampered as well.

Regardless of the above, this is a nice idea:

9 Likes