Are you referring to that? “NNS community maintains the code that is run by all SNSs”
Are you reading it as “NNS does whatever it wants with the SNSes?” Not sure what’s the confusion
Practically every sentence, particularly in the first 3 paragraphs, cements the reasoning behind the relationship between the NNS and the SNS. Forget about documentation though and just think about it.
Permissioned SNSs (permissioned by the NNS) must run an NNS-blessed release. The NNS maintains and improves that framework. Each SNS decides if/when to upgrade. The SNS framework is also open source and can be deployed independently of the NNS, in a non-permissioned way. But in any case, the NNS blesses new SNS releases if there is to be a new release. That is at the core of what an SNS is.
If you don’t want an NNS-blessed and maintained framework for creating and managing flexible and extensible DAOs, you aren’t talking about an SNS. You’re talking about something more akin to TAGGR’s style of governance.
Why don’t you fork the SNS framework and adapt it so that ‘SNS-RONIN’ instances can modify anything and everything about themselves via the SNS governance process (it’s currently not designed that way at all, on purpose). Note that those instances could drift arbitrarily far away from each other in terms of functionality and implementation, which again, is the opposite of what the SNS is designed to deliver, and reasons are provided in the documentation you didn’t read properly.
My point is that in one breath you want progress, and would like to see a new parameter that each SNS can control. Sounds cool to me.
In the other you don’t want a new parameter or anything for that matter added to the SNS framework.
You clearly think SNSs should not run NNS-blessed releases. But as described, you’re no longer talking about the SNS framework and should probably take that conversation elsewhere.
This actually gave me an idea, what if Toko replaced the SNS?
We’ve coded a lot of the functionality anyway, and per-token/nft governance is in the roadmap. We’ve got multi-subnet scaling so technically it’s vastly superior than the SNS anyway. Eventually it could all be NNS controlled too, once we get rid of all the bad actors in the space.
Let me think about this. Maybe we just need the SNS to die off and migrate the remaining projects to Toko.
The SNS isn’t going anywhere, and there’s no reason it should do. It’s a very good concept that simply hasn’t been used very well for the most part, so far (everyone just went for the out-of-the-box cookie cutter approach, by and large). Now that the community can actually contribute to its development and maintenance it should unblock a bunch of much needed improvements. I for one, will be building up an extensive testing suite to ensure any future upgrades don’t introduce any breaking changes for the numerous prospective SNSs I’m working on.
Toko sounds like an interesting alternative, not a replacement. Very interested to see it in action, as the proof is in the pudding. I’m optimistic though - sounds great.
This seems reasonable.
I haven’t read the rest of this thread, but I assume that what you ended up settling on is not much different from your original proposal.
From just the original description, it seems that the “root” of the implementation is simply to add a new neuron field, yes? And this would get populated when voting rewards are distributed, right?
This would increase the computation load in at least a few ways:
- space to store this new data. Compared to the rest of the neuron, this wouldn’t add much.
- time to store this new data (fetch each neuron, and update this new field). Neurons are already updated (specifically, their maturity) though, so this wouldn’t add much.
- during upgrades, more space would be required to “freeze dry” the content of the SNS Governance canister, i.e. serialize (during pre-upgrade) and deserialize (during post-upgrade) all the state, including all neurons with this new field.
I think this increase would very probably be ok.
It seems to me, that people can deduce the data that you plan to plan to store explicitly, right? They could just infer this from maturity increases, right? Of course, if an SNS sets their voting rewards to 0, then, that wouldn’t work, but I think this is unusual.
Can you give a more concrete idea how this would be used and why the existing data is really inadequate? I mean, I understand that the existing data is not ideal, because it requires deduction, but tbh, DFINITY is trying to allocate more of its development resources towards NNS these days, so it would be good for me to know what people expect to get out of this.
Yes, this assumes an SNS that’s okay with a very blunt form of inflation. It also puts substantial complexity burden onto dapps, which shouldn’t have to track all of the edge cases (scan maturity frequently, diff new maturity with old maturity to establish the delta, track disbursals to ensure these are substituted back into the diff else the delta will be wrong, track staked maturity increases as well as maturity increases, else the delta will be wrong etc.). It’s basically not the right approach, and it’s not available to all SNSs as you mention.
In particular, I’m working on numerous distinct SNS projects, one of them in particular cannot have this sort of inflation because the tokens in circulation need to be precisely in balance with a reserve currency that backs it. Inflation occurs, but only in tightly controlled proportions based on factors that are external to the protocol. While the total amount distributed with each inflationary event needs to be dependent on external (but measurable) factors, the way in which that total is distributed to token holders should still depend on their stake and ideally voting participation (if it can’t factor in the latter then it’s not really a voting reward - but that’s meant to be the entire point).
Unusual, yes - but the usual SNS hasn’t so far been much to aspire to. We can make it easier for the community to build SNSs that have more effective reward schemes.
Please see the examples given as historical context where other SNS developers have requested this also.
Thanks. So, IIUC, the idea here is to enable alternative reward schemes, esp ones that do not involve minting SNS tokens, right? E.g. profit sharing for a service with paying customers, right?
Indeed, although it is also intended to support SNS minting (so to speak, in terms of distributions from a pre-minted treasury) that distributes precisely controlled quantites that can ramp up and down (rather than only ever decaying at a pre-specified rate, as the maturity feature does). Distributing those tokens according to voting stake + participation requires this feature for it to become practical.
Yes, I thank that’s a good example.
Just bumping the actual PR so it’s easier to find for anyone visiting this thread.
@daniel-wong please let me know if you’re waiting on anything on my end. I addressed all automatic requests (though one still hasn’t been registered by the system for some reason - https://github.com/dfinity/ic/pull/11078#issuecomment-5230427149)
No. I just haven’t had time, but I will very soon. Sorry for the delay.
Hi @daniel-wong, thanks for your feedback on the PR. All makes sense. I’ve responded with a question to make sure the further work I do on this is in the right direction.