RFC 0061 — Safe Network Token Distribution

Can’t say why @jlpell (wrote all this before I saw your tag edit). I’ve had very little to do with this RFC. I came back just the other week after a few months.
(I will try look at what you suggest though, next week)

I managed to raise concerns about one thing in the RFC (just the other day) which was thus excluded (unfortunately still mentioned in this thread though), and tweak some formulations to try make the options clearer to a reader.

The only other input from me was a few months ago, raising my concerns about such large share of supply being handled by a foundation. Committees and boards being funded by the network and holding most of the supply - that’s not a good recipe in my world.
Unless I’m mistaken (I can have missed it), that’s all that was ever discussed about that in the team (except for behind closed doors as management convened).

Reality vs Wishes

The problem in my view is this:

  • We don’t want large sums of tokens being controlled by sections.
  • We don’t want sections to be able to create tokens.

Why?

Because we don’t know of a secure way to do any of those now - nor do we know when or even if we will learn a way.

Thus, the decision to have total supply exist from start; all DBCs ever existing would come from the genesis DBC.

So, how are these remaining tokens distributed then, if not held by the sections?

The wish is to
a) Release them over time
b) Have decentralized custody of them

(Remember these two points. They are central to the reasoning from here on.)

To have sections hold them, or be able to create them, would solve both a) and b) immediately. If only we knew that we could code such a solution - in a timely manner and meeting all requirements (wrt security etc.).

To use some sort of non-PoW lock-box to accomplish a) and b) is a solution unfortunately equally unknown to us at the moment. The idea has been floated that we could device such a solution. We don’t know how, when or even if we can.

So what do we know here and now that we actually can do?

  1. Let all eMAID/MAID be the full SNT supply. (Thus no remaining tokens to be distributed.)
  2. Let the Foundation hold them.

That’s it basically.

Pros and cons

Pros of #1: Simplest possible, hands down. Everyone already has all tokens. The most secure solution. There is nothing to be hacked or misused.
Cons of #1: There are a few big whales holding most of it. There’s fear that they could hurt the price by dumping.

Pros of #2: It gives some sense of control of the situation. There is a board and comittee that can take good care of it.
Cons of #2: It gives some sense of control of the situation. There is a board and comittee that can take good care of it.

(If the meaning of #2 as a Con was lost on anyone, then there won’t be enough I can say to help there. It’s beyond my available time and skillset.)

So, what this RFC says here in my view:

We wish to code a solution to a) and b), and when we get to it we will really try to do so.
Should we fail, there’s option #2 (the Foundation).

An observant reader would say, Hey, you forgot to mention option #1.
It’s not forgotten. It’s just not mentioned. I cannot give any answer as to why. It’s someones decision.

Why like this?

From what I’ve picked up: The reason for this to need an outline here and now, is regulations. FINMA. There’s an application that needs to go in there pronto, and there needs to be some outline making somewhat sense to regulators.

Because saying we will try to code a solution, and if we can't.. well then we don't have a plan B, I suppose isn’t an acceptable answer.

That’s why the RFC looks like this, is my guess.

Enter the Community

Now, welcome community, and solve this for us all; what other ways are there?

There’s the not mentioned option #1. Can you stomach that over a foundation? Then push for it!

Something else? Then PUSH for it.

If you don’t, then this is what you’ll get.

And please do it in the most professional and civilised manner you can. Put in the time, the effort.
It is my perception that a few with lots of influence on the path of MaidSafe and SAFENetwork, are not so impressed by the community (nor any crypto community for that matter). Crassly extrapolated, just to give a sense of what I mean, they tend to see a squabbling, unrealistic, idealistic, crypto-anarcho herd (again, my extrapolation of observed conversations, take it for what it is). I often feel the need to remind that there’s real people with real skills in the community. The herd is there, but many others as well.
So, make your voice heard and make an unmistakable effort to solve the problems. If the intention is not clear enough, all impression that is left to someone already skeptic, is unfortunately that above mentioned. A small team like this needs a vocal community, otherwise there are a very few deciding an awful lot (while probably not feeling like that’s an issue at all).

My couple of cents. Make of it what you will.

31 Likes