RFC 0061A - Safe Network Token Distribution (Dogmatic Edition)

Autonomi Network Token
,
1

This thread is a proposed revision of RFC 0061 based on one community member’s review of both the original Project Safe Whitepaper, RFC 0061, and a variety of discussions held on this forum between MaidSafe and The Safe Network community over the past 8 years.

The majority of the text is unchanged from that provided in RFC 0061, but there are in fact notable changes. Some of the revisions may be very subtle. If you care about this, please read carefully when comparing differences to prior proposals. Much of the rationale for these changes have been discussed in the original RFC 0061 thread, but this thread can be used to continue the discussion if desired.

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,294,967,296 whole SNT will be issued. This ensures that the originally promised maximum upper limit of 232 whole tokens cannot change over the life of the network.

Subunits & Divisibility

At network genesis, each whole SNT will be subdivided into no less than 1 billion parts (109). This shall create a minimum of 4,294,967,296,000,000,000 available currency subunits. As development of the network continues from the present into the future, this level of divisibility will be reassessed from time to time to determine if it is economically necessary and/or technically feasible to split each subunit into additional parts. If a decision is made to increase the number of total currency subunits, it will occur in multiples of 1000 to yield a total subunit count which represents a single whole SNT ranging from 109 to 1012, then 1015, 1018, 1021 and so on up to an absolute maximum of 1066.

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:

As literally interpreted in the original Project Safe Whitepaper, remittances of Network Royalties will be initially subdivided as follows:

  • 5% of Network Royalties will be focused on Core Protocol Development. This will support the global team esponsible for continuous improvement of the core network protocols and features.
  • 10% of Network Royalties will be set aside to support an Automated Direct Distribution system for Resource Supply Rewards and Network Royalties that is autonomously administered by the Network itself.
  • The remaining 85% of remitted Network Royalties will be managed by the Safe Network Foundation, a Swiss Non-profit corporation, to fulfill its other objectives such as Public Data Accessibility and Governance. This portion may be reduced to the absolute minimum required to satisfy administration and compliance requirements if the development of a fully automated rewards system comes to fruition.

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 Network 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 the 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, endeavors, 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 regularized on-going funding such as a Service Level Agreements (SLA).

Ad Hoc Payments

The Foundation may also make ad hoc payments to meet specific genesis token obligations in accordance with the original Project Safe Whitepaper, to fulfill the stated objectives of the Foundation, to remit its governance and regulatory obligations, and to cover its costs for 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 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 at the official launch of the Network will be distributed as follows:

MaidSafeCoin Holders

MaidSafeCoin is a proxy token, issued as part of a crowd-sale in April of 2014, that offered an immediate utility to the broader Safe Network Community as a branded Omnilayer based cryptocurrency embedded within the Bitcoin blockchain. This “colored Bitcoin” has been used as a general medium of exchange to support community sponsored activities and helped support long term development of the Network by core developers. Buyers that pre-purchased Safe Network Tokens in this manner were promised a 1:1 exchange rate with the Network’s native token at a time when it was demonstrated to be as stable and data secure.

An allocation of 429,496,729 SNT will be exchanged for the same quantity of MaidSafeCoin tokens Tokens will be distributed to MaidSafeCoin holders in a technically feasible manner (ex. airdrop, key signature proofs, burn address etc.), where the owner of any MaidSafeCoin will receive the same quantity of SNT at a 1:1 ratio.

This represents 10% of the total supply.

MaidSafe Shareholders

Each company share of Maidsafe.net Limited will entitle the bearer to 105.822 SNT, resulting in shareholders being allocated 214,748,364 SNT. Tokens will be paid out to shareholders in three installments over the period of a year following the launch of the Network. Any unclaimed shareholder funds will be held by the Foundation indefinitely.

This represents 5% of the total supply.

Network Royalties Pool

Out of the Genesis Supply, 644,245,094 SNT will be allocated to a Network Royalty Pool and distributed as Network Royalties.

Upon official launch of the Network, 1/3 of the initial Network Royalties pool will be used to meet core network development obligations promised in the original Project Safe Whitepaper, and to correct for a technical error that occurred in 2014 during the creation of MaidSafeCoins. All obligations to be satisfied via Ad Hoc Genesis Payments sum to 214,748,364 tokens (equal to 5% of total supply). In particular, they consist of the following three payment classes:

  1. A sum of 23,055,683 tokens will be used to correct the MaidSafeCoin overmint error that occurred in 2014. These tokens will also be exchanged 1:1 with MaidSafeCoin or eMaid following the same procedure and timing used to deliver SNT for all other MaidSafeCoin holders.**
  2. A sum of tokens worth $100k at fair market value will be distributed to those who worked on early project coordination and the Project Safe Whitepaper prior to its publication in 2014.
  3. After fulfilling payment classes 1 and 2, the remaining tokens set aside for Ad Hoc Genesis Payments (but not more than 191,692,681 tokens) will be delivered to members of the core development team based on their relative contributions to Safe Network Development. An objective and standardized metric will be used to determine the token value of individual contributions.

Footnote: The maximum total number of MaidSafecoin and/or eMaid that will be exchanged for Safe Network tokens is 452,552,412. This is equal to the sum of 429,496,729 primary tokens and 23,055,683 overmint tokens described above. In totality, all SNT tokens to be exchanged for MaidSafecoin and/or eMaid represent 10.5368069373% of the total SNT supply. The eMaid tokens are those Omnilayer based MaidSafecoin which have been immutably transferred from the Bitcoin blockchain to the Ethereum blockchain at the sole discretion and decision the individual coin owners/holders.)

After fulfillment of core network development obligations, the remaining tokens in the Network Royalties Pool (equal to 10% of total supply) will either be managed by the Foundation and/or distributed according to a Network automated rewards protocol to reward Safe Network Core Protocol Development, Client Application Development, Service Development, Public Data Accessibility, and cover the cost of Foundation Governance and Administration.

The Network Royalties Pool (including initial Ad Hoc Genesis payments issued therefrom) represents 15% of the total supply.

Resource Tokens

The remaining 3,006,477,109 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 Resource 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.

7 Likes
2

@jlpell First up congrats on doing the work to produce this.

Secondly my response below is mostly commenting on possible issues that may need fixing in your document but also I may point out things where you have not dogmatically kept to the law of the white paper.

This sounds like there is a shortfall and only the early ones will get their exchange. I know this is trying to account for the other 23 million not included here. But maybe if you do the suggestion below you do not need to confuse it more by creating the feeling there is going to be a shortfall and people will miss out at the end.

Basically this is the same as saying the approx 10.5% SNT will be exchanged with MAID on a 1:1 basis and approx 14.5% will go to initial royalties. Why not just say this as the initial royalties distribution.

IE

An allocation of 452,552,412 SNT will be exchanged with MaidSafeCoin tokens. Tokens will be distributed to MaidSafeCoin holders in the form of an airdrop, with each MaidSafeCoin entitling the bearer to one SNT.

This represents the MAID holdings existing. This is 10.5368% of the total supply^ [explain in a foot note why 10.5368%]

…

Out of the Genesis Supply, 621,189,411 (14.4632% total supply^) SNT will be allocated to a Network Royalty Pool and distributed as Network Royalties.

This way then the true picture is given and people are not first presented with the fear they will miss out on the exchange, but see the correct picture of what is happening.

The foot note (^) can explain that oversupply caused the problem and initial royalties had to be adjusted down to 14.4632% to account for the error.

The way it is done in RFC0061A is overly complex to explain and the fact it is no different than my suggestion above excepting the perception that there is some people who will miss out at the end. This perception will not be relieved since they don’t know that section 3 represents the remaining amount.

Finally why isn’t the 2^32 tokens backed/stored on 2^32 data objects? That is 1 SNT per data object. This is supposed to be dogmatic after all.

The idea of physically destroying the coins when receipted by the network provided a fairly unique way to disconnect the purchasing algorithm from the rewards algorithm. Also the coin creation by the network is now gone.

3 Likes
3

Yes, this is exactly right. Whichever way you want to dress it up, it’s changing the allocated distribution %s, and should be clearly stated.

And there are other issues too:

This spells trouble from a distribution point of view. These tokens cannot be held in the Network Royalties Pool. They need to be distributed by the same airdrop method as the other MaidSafeCoin allocation, and thus would need to be included in the genesis distro. Which changes the %s accordingly, as mentioned above.

It’s not going to be possible for the Foundation to hold these 10% back, and then have the Network automatically distribute them as tokens will not be able to be held by the Network; and the method for getting funds into the Network for distribution will be through data payments.

So, you may as well have the Foundation utilise the funds as per the original proposal (and as per the spirit of the original paper) and have them readily circulating through the economy.

There are other ways to “literally” interpret things in the original paper.

It’s strange, on the one hand you are sticking to bits of it like it’s an immutable religious text, and on the other, you are either ignoring or adapting it to suit your view of the intent of the paper and the overall project.

Just another example, you’ve left out that the…

… Foundation will: House the MaidSafe team in an HQ

Should the Foundation still do that? If we are going the dogmatic route, then sign me up for a corner office! :stuck_out_tongue_winking_eye:

But that’s the thing, it’s not a religious text, and it’s been written in a way that is both vague, contradicts its self at points, and is overly rigid in places and leaves no room for changing circumstances, and also can be interpreted differently by different people. (Oh, wait, maybe it is a religious text! :laughing)

We’ve walked a line with RFC 0061. It’s in the spirit of the original paper, the spirit of the project, the commitments to stakeholders, takes into account the changes and developments of the past decade of the project, and aims to leave enough latitude to accommodate future changes and challenges too.

That last bit is important… because there is every possibility that we could end up in the same situation in a few years with how we write this one if we are overly dogmatic and don’t write things with the future in mind.

9 Likes
4

The whitepaper stated:

  • A quantity of 429,496,729 coins will be available for purchase, this equates to 10% of all safecoins

The deviation from the whitepaper came when more than 10% were unintentionally issued, which is just one of those things, and likely helped fund the development of the network, so that’s all good.

But, there’s no need to deviate from the promise that the coins ‘available for purchase’ in the crowd sale will equate to 10% of all Safecoins, which means current MAID including overmint must equal ~10.5% of total supply.

I agree with @neo that just stating 10.5% and then explaining it in a footnote is simpler than having it in 2 pots & 2 different claim procedures.

Absolutely plans will change over time in an R&D project, but the $7m changed hands based on information that makes up a financial promotion that stated that the tokens available for sale would equate to 10% of Safecoins, so really this should be kept to avoid nasty issues in the future.

Ayway, after all this back and forth, if RFC 0061A were changed to clearly state the 10.5% to MAID holders and ~14.5% to network royalties to clarify things and sort out the distribution challenges you mentioned, would you be happy to move forward with it?

It seems to solve the blocker, and if there are no other blockers I guess everyone would unite behind it… I hope so anyway :laughing:

5

There are numerous other parts to it though, not just that, so not wholesale no.

But even on the 10.5% there are other nuances to consider, but we will do so

6 Likes
6

Interesting that you saw 10% of the total tokens as the important part when speaking your mind.

Two very valid views come from this is that:-

MAID represents ~10.5% of the 2^32 which is breaking the original plan and that the foundation must give up some of its stated amount to account for it breaking the (not-actually) financial prospectus.

OR

MAID represents 10% of the tokens, keeping to the 10%, and increase the max supply which breaks the max supply from the paper.

Remember the white paper was just that a white paper, not a financial promotion or prospectus. As a white paper it described a plan for a project and talked about the idea of a place holder coin and concept of how it would work. It was not a contract, prospectus, legal document, contract, or such thing.

So Maidsafe was between a rock and a hard place where a decision had to made as to which to keep, the 2^32 and the problems it creates or the 10% of max supply and the problems it creates. Because years has past and the markets have set a value and worked with the 10.5% of 2^32 existing and knowing this is 10% of SNT I guess Maidsafe choose the simpler route to take which the markets already adjusted to. To revert back to the letter of a plan (not contract, not prospectus, not legal document) would then mean the markets will readjust again and maybe give up. While keeping to 10% will prob see markets react, it will not be as much since that is the info they worked on anyhow for years.

[EDIT: @davidpbrown Just read way up in the other thread you asked for a tl;dr The above may help a tad.]

3 Likes
8

chatGPT comparison of the last proposal to this one

The first passage was proposing a white paper for the distribution of Safe Network Tokens (SNT) with a maximum supply of 4,525,524,120 whole SNT, starting on June 23, 2022 and superseding the original Project Safe White Paper 3. The second passage proposed the same type of white paper but with a different start date (January 22, 2023), and a different maximum supply of 4,294,967,296 whole SNT and a different superseding document (original Project Safe White Paper 1). Additionally, the second passage mentions that at the network’s inception, each whole SNT will be subdivided into no less than 1 billion parts, and the divisibility will be reassessed in the future to determine if it is economically necessary and/or technically feasible to split each subunit into additional parts. The second passage also mentions that the remittances of Network Royalties will be initially subdivided as follows: 5% for Core Protocol Development, 10% for an Automated Direct Distribution system for Resource Supply Rewards and Network Royalties, and 85% for the Safe Network Foundation to fulfill its other objectives such as Public Data Accessibility and Governance. The first passage did not mention any subdivisions of the remittances of Network Royalties.

2 Likes
9

I won’t rise to your tone, but for clarity; ‘tokens available for sale equate to 10% of Safecoins’ + ‘0.5% overmint (which weren’t available for sale at the Crowdsale)’ = 10.5%, which is consistent with what I said when you determined that I was ‘speaking my mind’.

Changing the 10% to 10.5% of the 2^32 is merely acknowledging & accounting for the overmint in a way that keeps the promise that Crowdsale tokens will equate to 10% of the total supply. The overmint itself was where the original plan was broken… though perhaps to everyone’s benefit.

The foundation doesn’t necessarily need to give up it’s allocation. It could come from the 70% allocated to future node operators if the foundation could make better use of the tokens. It would only represent a ~0.7% reduction in funds for node operators and would have no real impact on the network’s success. I’m also aware that this may mean that ~30.5% of tokens would be minted ahead of farming rewards being enabled instead of 30%, but the foundation funds certainly won’t be dumped on the market, so it shouldn’t have any negative price impact, and the foundations actions should help support things that will help the ecosystem develop, likely being better for price.

There are multiple examples of companies being sued based around ICO activities when all they issued was a whitepaper. While I hope it doesn’t happen, and I’m not a legal expert, it does seem like a real risk to not make the crowdsale tokens equate to 10% of the total supply.

Beyond that, in terms of integrity, if crowdsale participants were offered 10% of final supply, why give them ~9.5%?

I don’t think the market has been anticipating an expansion of the total supply by ~5% from what was stated in the whitepaper. I wasn’t expecting it, and it seemed the increase would only affect MAID on the market ahead of launch, not total supply on the Safe Network.

To me and a number of others, it’s a big deal to change the planned allocation to crowdsale participants from 10% to 9.5% when it’s not necessary.

Anyway, I think the arguments for the Crowdsale participants receiving 10% of total supply have been made and heard by MaidSafe. They will weigh up the risks and options and proceed as they see best.

The debate over the last few days seems to have been initially productive in highlighting this point, but it has descended into a bit of squabbling in the last few hours… I think I’ll bow out and just see how it settles with MaidSafe and trust they’ll find a good way forward.

6 Likes
10

I guess the question to me ultimately comes down to, why would you willfully choose the option that hurts supporters and believers of your project, many of whom have been around for nearly a decade, when you have the ability not to?

No matter how slight you may perceive the harm to be, it’s undeniable it exists. If either option has its ups and downs (although I see little actual upside to the original RFC), then what is the point of taking the original proposed path over this adjusted one?

If the only real upside for the original is simply inertia, then fine, so be it, but I find it odd that people wouldn’t see the merits of this path over the original. People are literally arguing against their own self interest. Why? I understand people like the project and like the team, but in the end, Maidsafe is a business, not your friend.

4 Likes
11

Subjective.

There are good and bad points to both RFC’s. But there is no way to predict the future outcome in the market. Therefore one can easily deny that a harm exists within either RFC as the future market state is an unknown.

This is unclear, but I’ve heard it stated by Jim that there are other factors (tradeoffs?) that he hasn’t stated or clarified yet. Perhaps because of back and forth with legal team – which undoubtedly needs time to process this work and draw up a report on their conclusions.

IMO many in both of these threads are being impatient with the process.

Let’s wait for Jim & legal to process & return with more details and answers.

2 Likes
12

I updated this RFC to include @oetyng’s suggestion that he made in the other RFC 0061 thread. Here are the changes:

I also renamed “Remaining Tokens” to “Resource Tokens” and modified some language about Maid owners here:

13

Still the problems of word play/hiding stuff.

The taking the 23 million from the resource pool is no different to the real situation of reducing the initial allocation to the resource pool. The repay is logically never part of a resource pool.

The real situation is there is the ~10.5% of 2^32 MAID in existence and as the dogmatic view is to do a 1:1 exchange for all the MAID (every MAID is the same as every other MAID), not a first come first serve on some and then smoke and mirrors the rest comes from an improper source of the resource pool. Its not financially sound.

Also the wording of first come first serve is always associated with not giving to all but only those who get in first. This is also a lie since the promise has always been everyone gets 1:1 exchange of MAID for SNT and the wording tells people that is not the case.

The truth and sound way of saying it is to say that all MAID holders will get the 1:1 exchange.
I.E.

An allocation of 452,552,412 SNT will be exchanged with MaidSafeCoin tokens. Tokens will be distributed to MaidSafeCoin holders in the form of an airdrop, with each MaidSafeCoin entitling the bearer to one SNT.

This represents the MAID holdings existing. This is 10.5368% of the total supply^ [explain in a foot note why 10.5368%]

And

Out of the Genesis Supply, 621,189,411 (14.4632% total supply^) SNT will be allocated to a Network Royalty Pool and distributed as Network Royalties.

Your wording is doggy smoke and mirrors whose purpose seems to be trying to keep wording the same as the white paper. In other words lying about the overminting and then using an invalid method of stealing from resource pool without telling the truth that you reduced the initial resource pool by the ~0.5%

If you persist in your wording then there is no way I can support a misleading RFC designed to hide the truth with smoke and mirrors, And such words will not get past any regulatory body (as far as I can tell)

Fix that first.

14

First I’ll respond to some prior comments, then I’ll add another reply that describes new revisions to RFC0061A based on your comments.

These are rather unfair and disingenuous comments imo. The whole point of this RFC is to be completely candid, in a manner that maintains the literal constraints imposed on SNT distributions by the initial Project Safe whitepaper while also explicitly describing the adjustment needed for the technical error that occurred in 2014. At the same time it updates some terminology/names of categories to match that which Jim/Maidsafe have recently evolved (ie. “Royalties Pool”, “Genesis Supply”). There are no smoke and mirrors, but rather a more accurate and explicit perspective than what you may be thinking based on how RFC0061 strays far too far from the whitepaper.

You are conflating the term “Resource Pool” (70% of total supply used for future node operator rewards) with the “Royalties Pool” (30% of total supply used for past, present, and future activities). The simple truth is that the original overmint of ~23 million Maid represents a quantity of SNT whose value was already delivered to the core development team. To take the value of that quantity from a different source, means the core development team receives the value of those tokens more than once.

The fairest solution for all parties involved past-present-future is to deduct this quantity from the 5% of total supply that was promised to the core development team (as a type of royalty for work performed to get to launch) in the original whitepaper as @oetyng suggested. To reiterate, there are two reasons why this is most fair:

  1. The core development team (as a group/entity) is originally responsible for the technical error which resulted in the overmint. (Not blaming anyone here, glitches happen.)
  2. In the context of the original plan proposed in the whitepaper, the Maid resulting from the core team’s technical glitch ( ie. the 23,055,683 extra Maid that were minted) were essentially a small advance on the (5% of total supply) safecoin/SNT promised to the core team in the Day 1 genesis injection. These given coins were already used by the core team. To take the value of these 23,055,683 coins from other parties (ex. the foundation, future node operators, Maidsafecoin holders) through an initial inflation of the total supply from 4,294,967,296 to 4,525,524,120 tokens is the least ethical solution and a direct violation of the terms proposed in the original whitepaper.

One of the biggest problems with the original RFC0061 is that it does away with the 5% of total supply that was promised to the core development team as a form of royalty. Why haven’t you criticized that as smoke and mirrors doggy wordsmithing @neo? In RFC0061A, the intent is for all original safecoin/SNT distribution promises to be fairly kept.

I agree with you that a footnote of some kind that shows the total Maidsafecoin that will be converted, and the actual percentage that represents relative to 2^32 can improve clarity. However, you are focusing too much on final percentages rather than the integer quantity of Maid. It is the actual integer quantities that matter, relative to the total supply. The percentages result from the integer quantities. It is important to show that both the total integer quantities and the gross percentage allocations remain unchanged from the whitepaper to remove sources of confusion.

I don’t see what you describe as the “true” or “correct” view of what is happening. Focusing on percentages first rather than integer quantities of Maid/SNT is not a good means for describing the initial distribution and only leads to more confusion. This is why RFC0061 went so far astray.

It’s not overly complex. It offers a simple 1:1 correspondence to initial distribution promises in the whitepaper. RFC0061A explicitly covers all issues raised by the overmint glitch with respect to the original whitepaper. In contrast, RFC0061 obfuscates much of the details and violates previously promised terms, which exposes the entire project to significant and unnecessary risk.

The intent of the “first come - first serve” language was to imply that holders could decide when they choose to convert their Maid to SNT, and/or that it could take time for all 1:1 MaidSafecoin exchanges to be fully executed. Given the imprecise nature of that term, and the way that you immediately interpreted it to mean something else, I’ll remove it from the RFC for the next revision.

There is a clear and obvious partition between “implementation and interface” terms within the Project Safe whitepaper. RFC0061A attempts to hold exactly true to this partition, to the extent of the literal statements made in the whitepaper regarding distributions/royalties, while offering the smallest deviation to account for past technical error. It also updates some naming conventions or terminology as suggested by Jim in RFC0061 to improve clarity (ie. “Developer Pool” is now called “Royalties Pool”).

It is understandable that the code “implementation” details required to achieve the project vision may need to evolve over time as unknown technical or scientific hurdles are faced and overcome. However, the economic/financial “interface” to the project with regard to initial SNT distributions, 1:1 Maid conversions relative to a max supply of 232, and ongoing royalties are: 1) explicit, 2) literal, and 3) accountable terms that are defined a priori. Maidsafe defined and offered these terms, the wider community accepted them. My stance/argument is that any original promises that were made in the whitepaper with regard to the economic/financial interface of the Safe Network should be promises that are kept during the official launch.

15

This is your interpretation of the paper of course.

But for MaidSafe to be taking 5% of the entire max supply on day one, is not what any of the team are expecting nor asking for, and would certainly be somewhat :astonished:

16

In my view the best solution here is to describe exactly how the tokens are allocated relative to the initial percentages described in the whitepaper (10%, 5%, 15%, 70%) and then add a footnote as @neo suggested to state the actual percentage of all outstanding Maidsafecoin relative to a 232 total supply.

I made a second attempt to make the language more clear here. A third or fourth attempt is likely needed. I agree that it needs to be more clear that all the MaidSafecoin to SNT conversions will happen in the same way. There may be better methods than an “airdrop” though.

I don’t see why this is not possible. It is a trivial thing to do for a typical non-profit foundation/corporation. There is no technical limitation and Foundation bylaws can describe how this should be done.

See my response to @neo. The partition between what is immutable, and what is not, is very clear in the whitepaper and this RFC logically adheres to that partitioning in a self-consistent manner.

:joy:

Sincerely, although I do in fact like some of the content you generated, I also think you really-messed-up the commitments to past, present, and future stakeholders. RFC0061 takes huge liberties with terms in the whitepaper that should have been viewed as hard immutable constraints. This includes: 1) the 2^32 hardcap, 2) the actual value associated with the 1:1 exchange of Maid to SNT relative to the hardcap, and 3) the ongoing royalty terms for core developers vs. general developers vs. the foundation. Yes, the whitepaper had some vagueness, but when it comes to distribution terms one needs to proceed with the literal interpretation of how they were defined. Just like you and everyone else who has participated in the forum over the years, I’d like to see this project be successful. I’m not a lawyer, this is just one man’s honest perspective of ethics and risk. I’ve been so vocal in my discussions with you @JimCollinson about RFC0061 due to my belief that it represents a significant risk and I don’t want to see the team stumble due to some external attack vector after so many years of hard technical work and dedication.

No, that is what was originally proposed, and that is what the broader community agreed to. No one can argue with that. You have worked hard and the reward is proportional to the risk. If that amount makes you uncomfortable, feel free to share with other supporters who have invested thousands of hours of their time and energy for no direct compensation, or donate it to the foundation. After network launch and genesis supply allocation, individuals on the core team can choose for themselves. At least the terms of the whitepaper would remain in tact, with no other parties injured or negatively impacted, and thus no cause for complaint.

17

I’ll try and help clarify here.

What Jim means is that currently we don’t have a mechanism for the tokens to be autonomously owned by the network.

So there is no way to transfer the ownership of tokens into the autonomous network ownership.

There may be other ways to distribute of course, but if specifically looking at autonomous distribution, that is not yet developed.

4 Likes
18

This is the key point for which there has been no explanation.

Especially the RFC0061 punishes the participants of the Crowd Sale by decreasing their percentage of the max supply. This is mathematically indisputable, with possible legal consequences, and without any technical justification.

The stubbornness to continue with this mistake makes me think that the decision has been made and that there are some reasons, not clearly explained, for it.

For my part, let Maidafe do what it thinks is best. I only hope that another fiasco, like the Crowd Sale, does not happen again.

1 Like
19

I updated the RFC0061A to eliminate the “first-come first-served” language @neo and added a footnote about final Maid/eMaid percentages here.

Ideally, if MaidSafe can address the $100k obligation on it’s own, we can eliminate the vagueness induced by how many tokens this might be. That way we can get explicit integer counts as to exactly how many tokens are allocated in each class to make things clear for everyone.

20

You guys might wanna check the latest on the other thread.

4 Likes
21

I see. This is not the right thread for a broader discussion on that part, but technically speaking that goes back to notion of DBCs addressed to some network key or network authority that need to be quasi-randomly to quasi-deterministically accessed at a controlled rate. This doesn’t appear to be a huge challenge medium to long term, and the RFC accommodates for any technical hurdle by involving the Foundation. So I’m still not sure why Jim raised an objection to the way the RFC is currently written.