RFC 0061 — Safe Network Token Distribution

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

This thread is for the discussion and deliberation of the Safe Network Token Distribution White Paper (RFC 0061), found over on GitHub, but reproduced in full below:

Safe Network Token Distribution

Summary

This RFC sets out how the Network’s utility tokens will be distributed at the inception of the Network, and how they are made available to contributors over time.

Conventions

  • The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Motivation

The Safe Network has a utility token which allows for the exchange of storage, bandwidth and compute resource between node operators and users wishing to store data on the Network. These are Safe Network Tokens (SNT).

They also act as a means to fund and reward other contributions that provide utility and value to people who use the Network, and wider society, such as open source software development, sites, services, and publicly accessible data.

This paper sets out how these tokens will be distributed, and how they are made available to contributors.

Detailed design

Genesis Supply

At the inception of the Network a Total Supply of 4,525,524,120 whole SNT will be issued.

Subunits

Each whole SNT can be subdivided 109 times, thus creating a total of 4,525,524,120,000,000,000 available subunits.

Data Payments

Users wishing to store data on the Network, or edit existing data, pay the Network to do so in Safe Network Tokens. A Data Payment is made upfront and there are no ongoing costs to maintain data on the Network after this payment—content is made perpetually available after this one-time fee.

These Data Payment fees are immediately redistributed by the Network as follows:

Resource Supply Rewards

Nodes provide data storage, bandwidth, and compute resources to the Network.

If a Node reliably and verifiably stores the data they are entrusted over an extended period, and serves it a timely manner when requested, they qualify to receive Resource Supply Rewards through virtue of meeting the required Node Age.

Resource Supply Rewards are automatically distributed by the Network to the operators of these nodes when a Data Payment is received by the Section in which they reside.

Network Royalties

Network Royalties are a mechanism through which software development, services, and data which provide value to people that use Network, benefit wider society, and meet the objectives of the project, can be can be meaningfully rewarded and sustainably funded.

Network Royalties are paid in support of the following areas.

Core Protocol Development

Individuals, teams, and businesses that support, research, design, develop, and maintain the open source software protocol of the Network and enable its ongoing operation, enhancement and security can become eligible for Network Royalties via the Foundation’s Developer Program.

Client Application and Service Development

Operators and developers of software applications, platforms, sites, and services, that run on, provide utility to, and are freely available to users of the Network can become eligible for Network Royalties via the Foundation’s Developer Program.

Public Data Accessibility

Creators, publishers, and curators of data that is made publicly and freely available for the common good, can become eligible for Network Royalties via the Foundation’s Data Commons Program.

Governance and Administration

In order to provide adequate, sustainable and transparent governance to the Network and provide the required administration of the Developer and Data Commons programs, Network Royalties will also be used to cover the costs associated with the operation and work of the Foundation, and the distribution of Royalties.

Distribution of Royalties

In accordance with the needs of the Network, and its ability to meet its objectives, the Foundation will oversee the distribution of Royalties via the Developer and Data Commons Programs, through the following methods:

Grant Making

Royalties may be paid in the form of grants to fund new areas of research, prospective development of software, services, or other activities.

Rewards

Participants in the Developer and Data Commons Programs may also be rewarded inline with the utility and value of their contributions, endeavours, services, to the users of the Network and the project’s objectives in a given period. This may be in the form of one-off payments or regularised on-going funding such as a Service Level Agreements (SLA).

Ad Hoc Payments

The Foundation may also make ad hoc payments to fulfil its objectives and remit, its governance and regulatory obligations, and in order to cover the costs of administering and distributing Network Royalties.

Grants, Rewards, and ad hoc payments will be made from the Network Royalties Pool, with any unspent or unclaimed funds in a given period returned to the pool for further distribution.

Automated Direct Distribution

It is an aspiration that the Network have the ability to automatically distribute Royalties, reducing both the time for recipients to be paid and the costs associated with administration. Autonomous distribution is subject to ongoing research for protocol development.

It is assumed that automatically distributed Network Royalties would be paid by the Network from Data payments directly at source, without entering the Network Royalty Pool.

Initial Token Distribution

The genesis supply of SNT will be distributed as follows:

MaidSafeCoin Holders

MaidSafeCoin is a proxy token, issued as part of a crowd-sale in April of 2014, that supported the development of the Network and also allowed buyers to pre-purchase Safe Network Tokens, ahead of the Network launch.

Holders of MaidSafeCoin will collectively be allocated 452,552,412 SNT.

This represents 10% of the total supply.

Tokens will be distributed to MaidSafeCoin holders in the form of an airdrop, with each MaidSafeCoin entitling the bearer to one SNT.

MaidSafe Shareholders

Each company share of Maidsafe.net Limited will entitle the bearer to 111.5 SNT, resulting in shareholders being allocated 226,276,206 SNT.

This represents 5% of the total supply.

Tokens will be paid out to shareholders in three instalments over the period of a year following the launch of the Network. Any unclaimed shareholder funds will be held by the Foundation indefinitely.

Network Royalties Pool

Out of the Genesis Supply, 678,828,618 SNT will be allocated to a Network Royalty Pool and distributed as Network Royalties.

This represents 15% of the total supply.

Remaining Tokens

The remaining 3,167,866,884 SNT from the Genesis Supply will be distributed by the Network to contributors—such as those uploading data or Resource Suppliers—in an automated way, over an extended period, corresponding to the rate of Network growth as measured by the volume of data stored by its nodes.

This represents the remaining 70% of the total supply.

It is assumed that this process, which is subject to further research and development, will be in place for the inception of the Network. If it is not, the Foundation will hold these funds until such time as it is complete.

Should the Foundation board subsequently deem that this proposal is not a technically feasible and adequately secure way to distribute the Remaining Tokens, then they shall be distributed to MaidSafeCoin Holders, MaidSafe Shareholders and to the Network Royalties pool in the same proportion as the initial distribution, over an extended period.

Drawbacks

There are drawbacks to a foundation overseeing and handling any size of fund, namely:

  • Security implications of holding tokens
  • Costs associated with administration
  • The centralising effects of doing so

While these deserve to be highlighted and discussed, they can also be mitigated through due consideration to appropriate governance and through the development of automated distribution processes as noted in this paper.

Alternatives

Remaining Token Distribution Proposal

An alternative that was considered, which combined the two as yet unresolved aims, involved 30% of the Total Supply being issued as the Genesis Supply, and then the remaining 70% being issued and distributed by the Network over time, at a rate proportional to the growth of data on the Network.

While it would allow for both the gradual and controlled issuance of the remaining tokens without the need for the Foundation as a custodian, it does have increased complexity, and more significant security challenges associated with sections being tasked with issuing new tokens.

Resource Supply Rewards

Note that the term Resource Supply Rewards is an alternative name for what was previously called Farming Rewards. This reflects advice to use more precise terminology to describe the economic mechanism.

Unresolved Questions

With Regard to Subunits

As we are currently finalising the design of the Digital Bearer Certificates (DBC) system, the exact number of sub-units may be increased to provide further divisibility. This is subject to the results performance testing and security analysis.

With Regard to MaidSafe Shareholder Payouts

  • We are yet to define precisely what event constitutes the “launch” of the Network, thus triggering the process of Shareholder Payouts.
  • We are yet to determine if there is a requirement for the Foundation to hold any unclaimed shareholder funds indefinitely, or if it can be time limited.

With Regard to the Remaining Tokens

Under the proposal described, it is still a matter of research and development to combine the two aims of A. gradual release of the Remaining Tokens, while at the same time B. having the tokens be in the custody of the Network. This is a challenge due to the limitations of doing a one time issuance of Total Supply.

Subject to Forthcoming Papers

The Foundation is a Swiss non-profit organisation incorporated to support the security, privacy, and sovereignty of personal data and communications, the resilience and global accessibility of public data, the pursuit of a free and open Internet for the public good, and the ability of individuals and businesses to trade goods and services online without the need for middlemen, through the promotion and stewardship of the Safe Network protocol, it’s ecosystem, and related distributed ledger and computing technology

The Foundation’s governance structure, Developer Program, and Data Commons Program will be addressed in forthcoming papers via the RFC process, along with those detailing the specifics of the technical design of Safe Network Token and DBC system.

25 Likes
2

Will the foundation grow as the network grows?

Will the foundation always be in control of 15% once the total supply is reached?

1 Like
3

A couple of quick thoughts:

Under Detailed design → Genesis Supply it might be beneficial to include a quick review of why that number is chosen, if only to head off a lot of questions from those not up to speed on the technicals.

Under the section “Remaining Token Distribution Proposal” 30% Genesis 70% issued “over time” it is listing all the Cons: “increased complexity, and more significant security challenges” but there is no section for the Pros or way to better compare the two proposals.

As a layman so apologies if this is way of the mark and/or been addressed already elsewhere:

100% genesis “Automated Direct Distribution” Proposal Cons:

  • The automated distribution could also be argued to be complex and possibly pose significant security challenges especially if the value of SNT were to rise significantly. A huge honey pot guarded by “automated methods” of distribution on a network without any concept of time. What could go wrong? A few exploits and 70% of the supply could be up for grabs in a short time span with little time for developers to react.
  • Can there be an emergency developer intervention by the foundation in case of these event, rollback of the damage? If Yes then now the network may at increased risk of legal/political related pressure if say the network hosts content that motivates censorship by powerful adversaries.
  • The image of network integrity would be degraded if emergency updates to protect the 70% honeypot ever need to be enacted, even if successful in stopping/reversing the exploit. Ethereum classic blunder.

30% Genesis "Remaining Token Distribution Proposal possible Pros:

  • 70% of the supply is not created, does not exist yet and therefor perhaps less susceptible to being stolen or siphoned off at a rapid rate like may be possible with the “Automated Direct Distribution” method.
  • Rate of issuance of newly created tokens would likely be variable depending on resources requested/required to SNT ratio or similar, so the actually amount created by distributed section(s) at any one time could be kept manageable low in line with what the network requires. Main benefit: Much less available to be stolen at any one time.
  • Any exploits that do arise can be addressed via normal distributed network upgrade process without major emergency event or risk of devastating loss.
  • Less need to reverse the stolen SNT calling into question the integrity of the network (Ethereum classic blunders).
  • Less probability of political/legal pressure on foundation when there is no honeypot.
6 Likes
4

Perhaps a little bit unclear what you mean here… the Foundation as an organisation will probably grow in size (e.g. take on more administrative staff) as the Network ecosystem grows, and/or the size of funds it administers increases.

Yet with technical advances as described in the paper are realised, such as automated royalty payouts, then it could reduce.

In this specific proposal, the Total Supply is created immediately. 15% goes into the Network Royalties pool and can begin being distributed by the Foundation via its various programs.

At the same time 15% of ongoing Resource Supply Rewards will hit that pool too, each time data payments are made by people storing data on the Network.

The job of the Foundation (as a non-profit) is to pay these out for the betterment of the Network and the advancement of the protocol, and to serve the project objectives.

It could technically hold more than 15% initially I guess, but it’s not there to “control” a certain amount of the supply.

And with automation, its admin role would be much reduced.

2 Likes
5

Yes, fair point.

Just to mention quickly here: the Total Supply is x10 the total MaidSafeCoin supply.

I guess this is the way the RFC process is set up, and its process.

It’s designed so that a single proposal can be evaluated at a time, rather than weighing the pros and cons of two different options. As such you layout the proposal in detail, mention any drawbacks, and alternatives that were considers before arriving at this one.

I suppose the aim here is to get more focused decision making.

If the alternative 30% genesis were to be considered in more detail, then it would be the subject of its own RFC.

6 Likes
6

The concept we are currently looking at doesn’t involve a single-pot, rather spreading out the supply across network addresses. It would also likely be less complex with fewer security implications than the on-going issuing/emission implied by the 30% Genesis proposal.

Granted though, that the Foundation holding the 70% supply fo a period would create such a honeypot, and we would like to try and avoid that.

The Foundation won’t do any development itself. It would be down to core developer teams, such as MaidSafe or others.

7 Likes
7

Apart from the security implication of some large % being readily available to be siphoned off, Vs a different method where that supply does not exist yet (may never need to exist) and would have to be created before it could be siphoned off.

The point that caught my attention is that this RFC appears to introduce a bias for itself through comparison with another proposal that does not exist. I understand it is a close knit dev team so I imagine you guys have already dug deep on the Pros vs Cons and this RFC is just presenting the conclusion as to security benefits/complexity etc as raised in this RFC vs the other possible path. In that case the bias is fully justified. It just reads oddly for a RFC.

2 Likes
8

I should let the dev’s opine in more detail here, but the main security worry around it seems to be the fact that nodes/sections would be able to mint DBCs. A rouge one could perhaps just mint as many as it liked. Whereas if they are all minted upfront, that’s not going to be a vector.

Then there is the issue of supply verification/auditability, which appeared to be significantly more tricky with the alternative.

Perhaps the devs can clarify some more.

9 Likes
9

I suppose what I am worried about with both questions is the control of the 15% (or more) of SNT as this could potentially be worth an incredible amount of money and money can do strange things to people. Looking forward to hearing more about how the process of automating the foundations funds can be accomplished :+1:t2:

7 Likes
10

My only concern is that too much money cause foundation be a political place or networking based kaleutel like other blockchain project.

11

It would have been helpful to show some data on how other decentralized networks handled their distributions (initial and ongoing), the community+wider space’s response, and their current popularity+reputation. As far as I know, virtually none of the popular/reputable projects in the decentralized space have unfair distributions if not because of their innate motivation but at least because an unfair distribution sends the wrong message from the outset thereby damaging the network’s reputation amongst the public whose support it needs to become popular.

Given these, I think this RFC is pretty bad. The initial distribution is ridiculously lopsided with Maidsafe controlling 90% of the SNT supply (i.e., shareholders’ 5% + network royalty pool’s 15% + remaining tokens’ 70%). It’s pretty disappointing and surprising that Maidsafe rolled out a proposal in which they control 90% of the supply considering the ethos of the decentralization movement. In the only other alternative scenario envisaged in case the main one is not adopted, Maidsafe controls 66.66% of the total SNT supply (i.e., shareholders’ and network royalty pool become two thirds of the proportion per which the full supply is distributed).

There’s also the issue of the 15% dev tax in perpetuity on top of the 90% that Maidsafe initially already controls. This isn’t PtD, but a highly centralized system with plenty of opportunities for the same old problems that plague committees and foundation boards. This isn’t going to be any different. In fact, it might have already started per recent happenings and this current proposal as the goal of a centralized entity is to further grow its own power not reduce it.

Moreover, the foundation/dev tax is a lot higher than the few other networks that implemented similar dev/foundation tax, and it comes with multiple issues that I don’t have time to go into. But one of the issues with such a large perpetual dev tax is that it actually assumes that the network won’t be successful. Take for instance the ETH network. The ETH foundation has not seen a need to implement a dev tax because the considerable growth of the ETH network has ensured that the initial minor ETH apportioned to the ETH foundation has continued to be more than enough to cover its ongoing needs.

I suggest Maidsafe revisit the distribution proposal and be able to justify it with good established precedents.

2 Likes
12

Whole thing sounds great to me but to focus on this a bit, I am very happy to see that these apps/sites/etc being free is a requirement.

Obviously given that the foundation is a legal entity there will be conflicts with the nature of the network and how people use it. So for example JAMS may just let unverified users publish whatever they like but that may be deemed piracy. Whereas JAMStand can onboard and verify artists and allow more broad permissions such as clients downloading after paying for a song or paying out streaming revenue to a verified artist on a per play basis etc.

So would JAMS not be eligible as opposed to JAMStand possibly being eligible? Would JAMStand being so closely associated to JAMS make it ineligible? What kind of legal hurdles or features may have to be disabled or disallowed to appease regulators enough to receive a grant?

I’m assuming we don’t have all the answers on this yet and don’t expect that but just some questions I have looming.

3 Likes
13

MaidSafe don’t control any of the distribution after launch. The Foundation controls that, and I think your contention that other projects “don’t have unfair distribution” is questionable. The way the distribution is set up is specifically designed to create a much more equitable distribution over time than with either Bitcoin or Ethereum for example.

The Foundation will have a duty to ensure this while MaidSafe will have no say except as developers like any other team which wants to contribute to the core development.

It’s also noted that the preference is for an automated distribution so that even the Foundation can be removed from this responsibility, but that has to be technically feasible and sufficiently secure, and so cannot be guaranteed at the moment.

I don’t understand what you’re objection is. Everything I’ve written here was set out clearly in the OP.

EDIT: maybe it would help if you set out what you think would be a “fairer” distribution?

2 Likes
14

Your entire reply feels like an attempt at gaslighting. Did you read my original comment?

:rofl:

Because I feel like your reply is an attempt to confuse and detract from my original comment, I will not engage further. If you are serious, I suggest to take a moment and read my comment again carefully and try to re-engage after demonstrating that you understand it. Thanks.

2 Likes
15

I’m not sure how responding to your key points, including correcting an important factual error and highlighting relevant points taken directly from the OP is gaslighting but I guess you won’t be explaining that either.

1 Like
16

The Foundation is not MaidSafe, the Foundation is a Swiss non-profit, which will be subject to governance set out in a separate paper shortly.

MaidSafe is a core developer, applying for rewards under the dev program, and competing with other developers for those funds. After shareholders are paid out, MaidSafe doesn’t intend to hold any SNT.

And the RFC sets out how we don’t intend for the Foundation to control any of the remaining 70% of supply, and a path through should we not find a technical solution prior to launch.

This is PtD, and also provides for options that we’re not adequately covered in the original Safecoin whitepaper, such as PtP, and the costs associated with administration of the Foundation.

The 15% figure hasn’t changed from the original paper (published some 8 years ago!) just the flexibility through recognising that the Network will have changing needs over it’s lifetime. E.g. more core work might me required early on etc.

Also @happybeing beat me too it with this:

Both for the remaining supply, and app rewards, (and further, for public data) the intention, desire, and direction, is for automated solutions paid directly from the Network, and not even touching the Foundation at all. This hasn’t changed from the original paper, nor vision of the project, either. But we acknowledge that these are not straightforward to implement, and as such may need to come after the launch of the Network, through necessity.

We could decide to change these things, but I’m not sure the community is ready to give up on some long cherished and promising features such as PtD, and sustainable alternatives to funding OSS development, and open knowledge access etc.

7 Likes
17

If the tokens are divisible, why not just have a network total of 1 and increase the possible degree of subdivision?

18

Yeah, we don’t have all the answers on those kinds of things yet, and most of that will be the subject of the Developer Program deets. We’ll be getting into the weeds on all that in good time!

6 Likes
19

Because rounding errors would mean that you can’t distribute exactly one SNT per MaidSafeCoin. Also, it would be harder for anyone to see how this complies with the distribution promised originally.

2 Likes
20

Thanks for your response. I hope some of this reply doesn’t come across as bragging, and that you see it merely as an attempt to give you some background as to my level of understanding.

Also, my motivation is to see this network be the best and most successful one from the outset so that it doesn’t die off and then there’s a period of confusion as to which network will be the best one (read which one I should build on). And I feel like for that kind of sustained reliability and primacy, the network will have to get started on the right foot from the outset.

Then just replace “Maidsafe” with “the Foundation” in my original comment. This statement doesn’t allay any of my concerns.

I’m well acquainted with Swiss laws and business rules/structures. Therefore I say, so what? That the non-profit is Swiss doesn’t make it impervious to the same problems other non-profits suffer from. There are countless examples.

I’m really trying to keep a straight face here. The whole point of decentralization is to distribute such powers as much as possible. Only people with little experience don’t get all of the bad things that happen behind the scenes with boards and committees. I’m pretty surprised at you guys’ almost naive belief in such structures and attempt to tell those who’ve been there done that that there’s nothing to be concerned about.

Right. Maidsafe will totally get the same consideration as a no name dev that just applied. Totally. Just like a famous professor gets the same consideration as an early investigator for their grants submitted to an NIH committee staffed by their friends/themselves. Yep.

This just sounds corporate. Just trust that I speak corporate (was at the best firm of them all). So this also doesn’t allay my concerns. Note that I also found the “path through” concerning.

A lot has happened since 2014. Maybe it’s time for you guys to look at others and what’s possible? Sticking to the dogma from 8 years ago is maybe not a good idea given how much the space has changed in that time, the precedent set by other networks, and the tremendous amount of serious scholarship that has come out on the topic.

Again, it feels like you are not aware of the literature on the topic just from your comments. At this level and this late in the game, you guys should be aware of what has been tried and failed and what the scholarship is. You can’t just go in assuming that others haven’t thought about this or performed experiments.

3 Likes