RFC 0061 — Safe Network Token Distribution

Payments for upload are done via a DBC, so the section receives the DBC and then splits it up to reward nodes and the foundation.

Is this what you are referring to?

No, I am just wondering how the money is protected in a case of temporary network split or on case of data corruption etc. I guess I’m not understanding very well the whole system… Keys can of course be owned by on owner at a time, but the part of what the keys fit in, how is that protected, replicated etc. I don’t know if this makes any sense, really…

1 Like

Thanks for that Neo, it is important to understand the initial motivation. Was this debated, picked apart and analysed by the community elsewhere?

As I mentioned earlier the alternative also opens up to several new “targeted attack” vectors, equally and possibly even more devastating. Forgive the paraphrasing but you did sum up one facet well:

Once 70% of the supply is distributed across the network “somewhere/everywhere”, the focus of malicious people will be to game the many possible additional targeted attack vectors “automated distribution” method(s) will provide to them in order to get control of as many tokens as possible. It may not even be necessary to take over a section to do so but rather game the distribution algos and even socially engineer the offline governance structures as we have seen before. I would add that there are many types of malicious actors and one that aims to game the automated distribution “at a rate that doesn’t destroy the token “economy” nor attracts attention” is one only motivated by profit. We have seen quite a few cases in this sector where the aim of the malicious actor is to outright disrupt, degrade and destroy regardless of profit. I´ll wager there will be plenty of those types lining up for the Safe Network.

Following the line of thinking:

If sections can´t be trusted with this data, then why can we trust them with any data?

Leading to more questions (some rhetorical): Are there different levels of importance of data? So this particular “token” data is too important for a section, more so than other data we aim to handle and is a special case. What other more important data are we going to have problems with handling in the future? Will we then need methods to increase the security guarantees to handle “really important” data? So for one off the cuff example If one section is not secure enough, then perhaps two, three or more need to coordinate for “really important” data.

From a higher level on where is all this going and leaving aside the sadly too numerous cases of fraud, speculative excess etc that always come with it as sure as human nature. In the real economy and more so in CeFi and come-lately DeFi, there is natural move to a proliferation financial products that help get things done and solve real world problems. We all use them everyday even without being aware of it most of the time. The majority to make society better. SNT is just the first baby step. After and on top of it should come new financial tools and derivatives to solve some of these real world problems in a more efficient way that the Safe Network should hopefully allow. One tiny example discussed here previously would be the ability for individuals/companies to set up gift card issuing DBCs.

Will all this potential future fall in the “important data” category and require foundations, committees and the “automated distribution” scripts they control doling out genesis issuance, to be really secure? The distinction into “just data” and “important data so we can´t” is fundamental.

Additionally, there is also issue of audibility of supply. This becomes much a more complex and difficult problem to solve—and may be impossible while maintaining privacy—should the entire supply not be minted at genesis.

7 Likes

Its not so much cannot be trusted, but rather not making sections targets was the greater motivation.

I agree that sections should be capable of being trusted.

Your post is definitely thought provoking. I agree that DBCs could be introduced that deal with things other than SNT, but would have to use their own implementation. Maybe do a omni-protocol style of thing where they have a payload associated with a SNT DBC of a very small amount (1x10^-9). This could be achieved by encrypting data with key derived from the DBC itself and the data holds the info for alternative use. Obviously different things would require different ways to hold the alt data.

@JimCollinson Wondering if the DBC can hold a small payload, a minimum of an XOR address and decrypt key. Can this please be included as this would open up a huge area of secure asset transfers, Other coins, or any number of other ideas.

4 Likes

Each threat has different incentive structures and different kinds of impact and these are complex to understand and evaluate. So while this have been discussed on the forum I doubt we’ll get a full understanding of all the issues and it’s pros and cons. It requires deeper clearer thinking than we get here, although there’s no reason not to look at it again, maybe in a dedicated topic so that can be referred to if it comes up again.

For example, it is not true that being able to mint DBCs only has a profit motive. That could be used to disrupt the network by destroying the economy, rather than only milking it gently. That’s not hard to see but been missed immediately in this discussion.

As for “if we can’t trust the network to do this, can we trust it to protect other data?” that’s a valid question, best explored by asking what are the threats for the other data, the incentives, rewards etc for attackers. You can’t answer it with yes or no, but you can look at where the network is weakest and then decide how to make it secure enough for each aspect.

However, securing data isn’t an afterthought, the whole design has been created, adapted and changed over time to get a balance between security, efficiency, cost etc. If a new feature is then proposed, like having Sections mint or control vast sums, you need to look specifically at that. It doesn’t to throw everything you’ve done so far into question.

So there’s no need to suddenly doubt the suitability of the network to store other data. That’s not changed. By all means re-evaluate it, that can do no harm, but it doesn’t really belong in this topic and hasn’t suddenly been thrown into doubt because a different kind of threat is seen as too risky.

3 Likes

Very recently in this thread was a quick review on the limits of u64, u128. These are equivalent of hard “supply” limits. To breach those hard limits you would need to upgrade the libs DBCs use to handle more “supply” u64->u128, or fudge it and change the fractional system as you went over very well in the “Proposal for Nice Numbers”/“Many Units” post above.

I am guessing is the concern behind audibility of data as you mention: We may not have enough trust in sections to manage the data rules regarding issuance, even upto a hard supply limit provided by u64 for example. We should have enough trust in sections to handle the audibility rules for other data types however. Is that fair to say?

Why would there be more trust in “automated distribution” upto the hard limit provided by the genesis mint total but, not “automated issuance” upto the hard limit provided by u64 under the chosen fractional system? Is it not exactly the same problem? The key in my mind is: Guarantees about the overall rate of distribution/issuance which in itself is also appears to be the same problem for both methods. Perhaps the automated distribution methods envisaged are to have their rates of distribution controlled externally and so not dependent on any security guarantee´s of Sections/the Safe Network?

Note that the example is not even scratching the surface of derivatives that could possibly be built on top of SNTs (not involving new DBCs), but in the end all would ideally require depending on the security guarantees of the data auditing and handling aspects of sections and so Safe Network as a whole. A least if they were to be done in a decentralised way.

See my wager, bottom of third paragraph in my previous post.

Happy to see new (and old) threads on this topic. Any references to the last time it was looked at would be appreciated so I can get up to speed on the thinking here.

2 Likes

Different contexts are being mixed here (technical, governance, etc.), but to the spirit of the message that the community should just defer to Maidsafe/Foundation on all matters, I would advise reading this piece by Maidsafe’s own Head of Policy and Governance: The speculative fiction novel I want to read this year – Hi, I'm Heather Burns.

Here’s a quote from the piece, but I advise everyone here to read the whole thing in its entirety because it’s very relevant to the prevent discussion. “

"To its credit, the open source project has a global, vibrant, and wonderful contributor community spanning nations, races, skills, abilities, and perspectives. To its demerit, the project has no transparent governance, decisions about the project are not made public, and project officials are not elected by, accountable to, or removable by the open source community.”

I’ll come back to the governance vs distribution dichotomy and why it’s so hard to disantangle the two.

By the way, I would think that for a discussion like this, the Head of Policy and Governance at Maidsafe would be participating and engaging directly with the community. I find it strange that that’s not the case.

5 Likes

@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

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

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

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

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

8 Likes

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

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

I appreciate the clarification

4 Likes

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

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

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

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