RFC 0061 — Safe Network Token Distribution

Seems like the ideas discussed here, here, and here do not solve the issue of allowing elders to create new DBCs. The August 18th post recognized “[w]e still need to figure out how to . . . make mining SNTs uneconomic for rogue sections.”

And in a post I made just last week, @dirvine said “[i]deally, we look to a solution where Elders cannot steal, I,e. they cannot create money.” He also explained, “[i]f elders created DBCs then they would not go back to genesis and not be valid.”

Something is not adding up for me. I need a clearer description of how the network will autonomously distribute 70% of SNT over time without creating a vector for a sybil attack.

EDIT: and will the supply still be auditable if there are Genesis events occurring frequently rather than once at network launch?

1 Like

Yes there are many questions here. I wish the 70% reserve could just be rethought, but I guess they want to stick to the original plan as much as is technically feasible. In any case, I hope that issuance is very low or at least on a curve that decline with time. It will be in competition with every other token out there, plus without a reducing release curve the network itself could be at risk of a large farmer shock at the end of it - which could literally destroy the network value proposition – perpetual data.

Many questions need to be answered, but I think they are still more focused on node communication and bugs at the moment.

2 Likes

Im little bit a bad in mathematics, if I have 1 safe token then in final network I get how manY multiplier? (If 450m is will be distributed) thx

It definitely shouldn’t hold back launch!

2 Likes

MAID are exchanged one for one SNT. Same for eMAID.

3 Likes

and in ipo or ico was 4.5 bilion or 450m? Max coins

Didnt the crowdsale link show where they would go?
It certainly answered

And

Most will be to reward future farmers and held back.

2 Likes

I’m glad to see that one other soul actually read/understood the suggestion. I don’t recall receiving any other feedback either for/against my recommendation. Seems like such a simple fix that would be obvious to everyone, but the the current RFC went out of its way to complicate the matter and make a mess of things imo. I’m quietly hoping for a revised RFC, call it RFC 0061A, that will arrive and describe an unchanged hardcap. :unicorn: :smile_cat:

5 Likes