Updated: RFC 0061 — Safe Network Token Distribution

[TylerAbeoJordan]

@jlpell

So yes @JimCollinson , you did break “the first law of crypto” here. After so many years of 2^32 mantra it’s part of the project’s DNA. There is a logical inconsistency here when one thinks that a promised and long considered hardcap can be so trivially changed.

I don’t see much import to this argument as comparing the white paper to a contract isn’t valid. A white paper is a sort of mission statement – one that lists specific aims and goals. But we all expect that some things will change as things are learned. What is of import IMO is why they changed and Qui Bono.

@jlpell

If this is the outcome it means that there was never a hardcap to begin with, and the original statement was a lie.

@jlpell

The history of the project needs to demonstrate evidence that promises made were promises kept.

Not a lie, it means the original statement was an estimate based on certain hypotheticals and intuitions. We expect to keep to those estimates if possible. However we’ve known for a long time though that something was going to have to change given the overprint and only a question of what the solution was going to be. So trade-offs have to be made hence leeway needs to be granted.

@jlpell

Since it is an a priori logical constraint by definition, and it was what everyone signed up for.

It was an expectation, but not a legal constraint. Similarly some would say that they “signed up for” MAID to be 10% of the total. But one thing or anther has to give.

What I want to see are arguments that demonstrate that keeping previous hard cap is legally or technically superior than keeping percentages fixed (both white paper hypotheticals). I’m unsure if it’s possible to make such an argument, but ears are still open.

@jlpell

Changing the hardcap also means that the promise of 1:1 exchange equivalent value between MAID and SNT is broken.

I’m not following the math you gave for this point. We are still getting 1:1 MAID for SNT. Perhaps you can clarify this point further.

@jlpell

The level of divisibility first described to in the whitepaper was 2^248.

Unlike the hardcap issue, I think divisibility could be changed later down the track if needed. So i don’t have any arguments for or against this issue.

@jlpell

This is where the problem I’ve raised about the hardcap is most easily solved.

I also have no arguments against your proposed solution - it’s a good and valid possible solution to the problem. What I’m looking for though, are arguments against @JimCollinson 's solution that addresses all issues surrounding the original issuance problem and that demonstrate your solution to be clearly superior. To my mind, I don’t think your solution is better or worse - it’s really unclear to me that it would change much if anything nor who would ultimately benefit or not from swapping solutions. So much depends on market forces that are unpredictable.

IMO and to reiterate and really at this point to beat the dead horse, for me this comes down to legal or technical reasons why Jim’s solution fails - and I don’t see any arguments here in that regard. I don’t mind your solution either, I just don’t see justification for Jim to change anything.

@jlpell

Again, the details and wording are important here. The perspective should be that by keeping the hardcap at 2^32, the original intent of swapping MAID for SNT at 1:1 is fullfilled at the same relative network value.

Yes the wording is important, but let’s not also make the wording more complicated … Your solution simply stated means that MAID/eMAID hodlers and investors are getting a larger percentage of the total.

And that is what I fear project detractors are going to latch onto. Again, nobody knows the market outcome of either solution, but it’s fair to say that there are negative aspects to both solutions.

That’s all I’ve got. I’m really on the fence solution-wise. I think Jim’s done the work drafting this up so my vote if I had one would be to leave it as is and to let Jim get on with other things. Still listening though if there are further clarifications.

[dirvine]

@neo

I secondly pose that to argue now about being pure & 100% true to the white paper is to trash much evolution of the project. Basically destroy the current project to revert to the white paper since even storage has changed, safesites have been added, NRS has been added, append storage, non-hopping (or limited hopping) proposed, and so on. The project has evolved in many ways.

This is my fear. The world has moved on significantly, and technology has moved on significantly. Regulations are a major change now too.

Almost nothing is as it was in 2014. So to me, the spirit of the whitepaper is everything and the detail is simply version 1. As long as the spirit is kept and the same people benefit (i.e. not diverting funds), I think it works well. Any changes to how these are distributed should be expected. I am strongly of the opinion if we have technical ways to not have humans involved then great, but right now, DAO and co are not fit for this purpose.

The difference from 2014 to 2023 is now we will have endless debates over this

[TylerAbeoJordan]

@dirvine

now we will have endless debates over this

Hopefully not endless!

I think people just want to have their say - make sure all avenues have been considered. After all, if you don’t speak up you don’t know if they have thought of everything - nobody’s a mind reader.

Most important in it all is that we remain decent to each other. I know I haven’t been very good at this in the past myself, but continue to work at it.

[dirvine]

@TylerAbeoJordan

I think people just want to have their say

This is the key part. I think frustration happens when we feel we are there and sign off and get all the legal in place etc. for the foundation and then there is that last wafer thin mint (all in good taste and meaning but tremendously hard to work with, we never feel we get finished, look at how long this has gone on for example)

So yes we all need to speak, and we all need to be heard for sure, but we must watch that last wafer thin mint

Monty pythons, Mr creosote, Full version,

[Bogard]

Very curious as to how and why would this update further delay network launch as is being claimed?

On the filing document side, you find and replace the max supply value and absolute values for the allocated percentages (the percentages themselves don’t change). You can also then add an addendum that ~23M of the royalty rewards is already in circulation. Done.

If someone was already reviewing, you make sure you enable track changes and send them the updated version with a note as to the minor change.

On the technical implementation side, max supply value changes. Done.

[happybeing]

This first has to be revisited by the team and one of several alternatives (3?) chosen and probably again put to the community after someone has updated the RFC.

All that takes time from the team and is that the end of it? Who knows

[Bogard]

We were told that the technical team, who is actually working on the rate limiting part of launching the network, isn’t involved in these changes/discussions. I’m still very curious as to why a very minor administrative filing change would delay a network’s whose technical implementation isn’t yet ready.

[dirvine]

@Bogard

I’m still very curious as to why very minor administrative changes would delay a network’s whose technical implementation isn’t yet ready.

These things form part of our bi weekly meetings. They are in our internal channels for discussion and are an enormous amount of work. Devs tend to keep out mostly, but they are not immune to the work. This then ties into the larger picture and again causes more work.

So there is a delay, it does take time, it is effort and it is distracting. I hope the devs are not too distracted but just look at the forum. We need to be getting to launch and moving forward fast and this is not it. It’s not a cop out or using launch as a weapon but nobody can consider all these delays in any part of it helps.

As I say it’s so emotional and seems to provoke the worse in genuine discourse that I am happy to keep out of it altogether as I do need to focus on launch. We do have a ton of discourse topics to finish debating in house and I think I need to spend time there.

This one can go on for a very long time.

[Bogard]

I appreciate the clarification. Here’s one approach to minimize that distraction. I’d summarize the two alternatives on the internal channel:

1. The current one: raise the max supply (percentages don’t change) to fix the overprint with a slight dilution of MAID holders.
2. The proposed alternative: keep the original max supply (percentages still don’t change) and fix the overprint with an ad-hoc payment from the royalty rewards.

And let the process take its course. Better get started with it than endlessly debate the ramifications of beginning the process. That only adds to the delays. (And I really sympathize with the fear for anything that could lead to further delays. I have it too. But the only wait to avoid the delays is to just get going.)

[Bogard]

To help keep focus on what really matters here, I’m going to edit that part out of my response. I suggest you do the same, stay focused on what matters and move forward.

[zeroflaw]

If there is no material difference between the two approaches. The how can doing the alternative cause a delay.

The reason it can cause a delay is because they are different.

[VaCrunch]

@zeroflaw

If there is no material difference between the two approaches. The how can doing the alternative cause a delay.

The endless debating over something not even that important is what can cause the delay. Move on, please.

[Josh]

@VaCrunch

The endless debating over something not even that important is what can cause the delay

Kind of agree but is the purpose of an RFC not to find problems and to fix them.

Might be better to call it an announcement, let those who disagree be upset but not get caught up in trying to make a case for change?

[DavidMc0]

@TylerAbeoJordan

It was an expectation, but not a legal constraint. Similarly some would say that they “signed up for” MAID to be 10% of the total. But one thing or anther has to give.

I see it that people signed up for the MAID issued in the ICO to paying ICO participants being 10% of the total, as this was expected to be the only MAID issued.

In order to accommodate the over-print, it seems clear that this 10% will need to become a higher portion (~10.5%) of the eventual Safecoin issuance if ICO participants aren’t to be diluted.

Regarding legal constraints, I don’t know how regulation will go in the coming years, but I would expect that allocating the ICO subscribers 10% of the eventual supply as advertised would be sensible, because if it effectively becomes ~9.5%, you can be sure some muppet would try to sue if that difference ever became a serious amount of money (not unlikely in the case of a successful network).

@jlpell

My suggestions amount to keeping everything that was originally promised in the white paper EXACTLY the same except for the smallest change possible to fix the overcommitted MAID

I would be interested to hear any arguments as to why keeping allocations as close to the same as in the whitepaper isn’t a good idea.

Changing token quantities and allocations seems like a real risk given how regulators may view it when people made what were, in the eyes of regulators, investment decisions based on the provided information. But of course, if it is necessary for good reason, then it must be done.

[JimCollinson]

@DavidMc0

In order to accommodate the over-print, it seems clear that this 10% will need to become a higher portion (~10.5%) of the eventual Safecoin issuance

This would seem at odds with this

@DavidMc0

I would expect that allocating the ICO subscribers 10% of the eventual supply as advertised would be sensible,

@DavidMc0

I would be interested to hear any arguments as to why keeping allocations as close to the same as in the whitepaper isn’t a good idea.

The proposal in this RFC is to do just that, with the overmint absorbed by the entire economy overall, and everyone having the same % allocation as per the original paper.

This seems the fairest way to do things, rather than adjusting anyone’s %. And, as others have pointed out, already priced in by the market.

[DavidMc0]

@JimCollinson

This would seem at odds with this

I don’t think it’s at odds - I’ll try to explain it more clearly; In my thinking I’m separating out the current MAID supply into A) ICO participants portion and B) the overmint portion.

I’m assuming that the 10% for ‘MAID holders’ was intended to mean ICO participants, and that the over-mint wasn’t an ICO participant.

So, of the ~10.5% of the eventual supply that is currently circulating as MAID/eMAID, in my view 10% should be allocated to ICO participants, and ~0.5% from the overmint elsewhere.

@JimCollinson

The proposal in this RFC is to do just that, with the overmint absorbed by the entire economy overall, and everyone having the same % allocation as per the original paper

This is where differentiating between ICO MAID and over-print MAID makes a significant difference.

The RFC as it stands means ICO participants % allocation has indeed reduced below 10% of the eventual supply because of the over-mint.

Taking that over-mint portion from elsewhere keeps the allocations the same for all existing participants & means there is no change to total supply.

[JimCollinson]

@DavidMc0

This is where differentiating between ICO MAID and over-print MAID makes a significant difference.

There is no way to differentiate them though, is there? Holding MAID, whether you bought during the crowdsale, or at a later point OTC, or via an exchange, or wherever, it still gets you 1:1 SNT. Because MAID was and is a proxy token for SNT worth 10% of the overall supply. There is no different class of MAID holders, ICO participants vs other holders, it’s all one supply, and ICO participants were free to sell at market rates knowing this.

And we have to accommodate the exchange for those proxy tokens in the same way no matter how or where they were purchased.

[zeroflaw]

The initial offering was sold as “10%”. (which did not include the overprint)

Suggesting that because the overprint was always part of the the supply, (and at the time stated as a mistake), however later required for funding, means that investors were “informed” is a bit of a stretch, in my opinion.

I think you should get someone with a legal background (a third party) to validate the above is acceptable, and that they agree its not mis-selling / breach of contract / bait-and-switch / some other securities law. I will shut up.

[JimCollinson]

@zeroflaw

I think you should get someone with a legal background (a third party) to validate the above is acceptable, and that they agree its not mis-selling / breach of contract / bait-and-switch / some other securities law. I will shut up.

Yes, we have such a legal team, and they are drafting an opinion based on this distribution, and that opinion has to pass via the Swiss financial regulator, FINMA, in order for us to create the token and launch the Network.

[zeroflaw]

Are they in-house or independent company?, if the latter, have them post an offical statement on the forum. With an explanation of why it’s acceptable. If I deem the statement to be sound, we can all move on.