Improvements for SNS treasury and other critical proposals & removal of following

[osman]

The offer is nice. However, the reluctance of neuron owners to participate in management may make management difficult. In critical decisions, it is correct to disable tracking. To make management easier, I recommend that critical quotes have two conditions. For the vote to be valid;
1- At least 50%+1vote of the total voting power must participate in the voting.
2- It would be appropriate to accept the proposal with the votes of at least 50%+1vote of the neurons participating in the voting.
In addition, it would be a correct decision to limit the amounts that can be withdrawn from the treasury, such as monthly or annual, for critical offers.

[lara]

Hi @modclub,

Will the percent limit on withdrawing from the treasury be on the amount remaining in the treasury or on the amount initially raised? If the former then would the treasury never be able to completely withdrawn?

This hasn’t been designed and would of course be discussed with the community. One initial idea was to have a mix of a maximum % of the overall treasury content and an absolute maximum but not apply the % for amounts that are very small (to avoid what you mentioned, namely that there is a certain amount that cannot be retrieved).

Also instead of a limit are there any other solutions you explored? Would it be possible to hold the funds in escrow for some time limit after a SNS transfer proposal is accepted and then a secondary vote, without following could occur that could cancel the original transfer.

This is indeed a solution that we also wanted to consider. I think once could argue that this would put the “work” to mobilise voters a bit on those who disagree with a proposal while requiring a larger threshold to begin with may put the work more on those who submit the proposal. One could argue that it should be the responsibility of those who want to make a change to invest this effort.

[skilesare]

@lara

The ICP ledger cannot be upgraded by the SNS. The SNS ledger can only be upgraded according to the upgrade path that was pre-approved by the NNS. Therefore, I think the SNS DAO cannot circumvent rules by canister upgrades.

It makes sense that the balances are held there, but I was more curious what (principal, subaccount) they are held by. Is that principal an SNS System canister or an SNS Instance canister?

[lara]

The principal is the canister ID of the respective SNS governance canister. The subaccounts are fixed constants that I have to check again in the code.

I am not fully sure what you mean by

SNS System canister or an SNS Instance canister

Let’s take for example the treasury of the Dragginz SNS. Then the principal controlling the treasury ledger account (on the ICP ledger or the Dragginz ledger) would be the canister ID from Dragginz’ governance canister (so particular to this SNS instance).
I am not sure if this should be called a system canister. But the code that this canister is running is system-provided and approved by the NNS (also see this documentation). In more technical detail, this canister can only be upgraded to WASM code that is defined in the SNS wasm modules canister SNS-W, which is a system canister.

Does this clarify your concern?
Happy to also follow up with the more detailed subaccounts!

[modclub]

@lara

This is indeed a solution that we also wanted to consider. I think once could argue that this would put the “work” to mobilise voters a bit on those who disagree with a proposal while requiring a larger threshold to begin with may put the work more on those who submit the proposal. One could argue that it should be the responsibility of those who want to make a change to invest this effort.

Yes I believe we have some agreement here. The BoomDAO scenario illustrates how a voter mobilization could organically arise, and by removing auto-follow for the secondary vote, it ensures that any project must secure active consensus rather than passive approval. If the opposition succeeds a cool off period for sns treasury proposals could also be implemented.

[memecake]

@lara

Increase the required threshold for all critical proposals: Critical proposals are only adopted if 50% of the available voting power votes in favor of the proposal. This also implies that such proposals can only be adopted if at least 50% of the voting power participated in the voting, as opposed to other proposals where 3% yes-votes and simple majority are sufficient to adopt a proposal.

Achieving this goal seems incredibly challenging, and it might be time to consider a viable workaround. We invested nearly three full days in garnering votes from the community for our funding proposal, yet we received only a meager 28% participation rate.

In any democratic process, voting plays a pivotal role, and when participation is low, it can pose significant challenges for projects.

One potential solution we can explore is implementing a time-based execution mechanism contingent on achieving a voting majority. Under this system, major proposals would be made available for user votes for a minimum period of three days, ensuring ample opportunity for community participation and decision-making.

[memecake]

@Seers

[For context, several DAOs have already withdrawn about 100K ICP (including Catalyze, Modclub, and Sonic). Meanwhile, Ghost DAO withdrew their entire treasury of 20K ICP to provide liquidity.]

FYI - Collecting funds through a democratic process aligns perfectly with SNS principles. Sonic has diligently raised awareness before initiating this funding process, and our objectives are transparent for everyone to see. The overarching goal here is not to stifle DAOs but to ensure fairness. When an individual decides to vote and self-elect without seeking the permission of users, it can lead to issues that need addressing.

[skilesare]

@lara

Let’s take for example the treasury of the Dragginz SNS. Then the principal controlling the treasury ledger account (on the ICP ledger or the Dragginz ledger) would be the canister ID from Dragginz’ governance canister (so particular to this SNS instance).
I am not sure if this should be called a system canister. But the code that this canister is running is system-provided and approved by the NNS (also see this documentation). In more technical detail, this canister can only be upgraded to WASM code that is defined in the SNS wasm modules canister SNS-W, which is a system canister.

Does this clarify your concern?
Happy to also follow up with the more detailed subaccounts!

Yes…this is what I’m looking for. I’d call that an SNS Instance Canister since each SNS gets its own Governance canister. This being the case, there would be two potential ways to currently to move treasury funds:

1. Update the Dragginz SNS Governance canister with a WASM that has a distribute function(I’m guessing this would have to pass an NNS vote as you say that only WASMs IDd by the SNS Wasm module canister can be installed.
2. Register your own Generic Nervous System function(https://github.com/dfinity/ic/blob/63d129a74be8cbd8ed9c905e4a40c0e41a055770/rs/sns/governance/canister/governance.did#L141) for distributing each type of asset. I’m assuming that when a generic governance function is called it is executed from the governance function?

[lara]

Yes…this is what I’m looking for.

Glad to hear that!

two potential ways to currently to move treasury funds:

1. with a WASM that has a distribute function

Correct. This would require an NNS approved new version of the SNS and therefore an NNS proposal.

Register your own Generic Nervous System function for distributing each type of asset.

This is actually explicitly not possible. The governance canister prevents the registration of generic proposals that target an SNS canister or the ICP ledger (you can see this here). This should ensure that SNS voters can always detect such important proposals as such. Also, this is to enforce some access controls and ensure they cannot be circumvented by generic proposals.

[daniel-wong]

Where are the treasury funds actually held?

Here is the code that determines where SNS tokens are held by the treasury.

Whereas, here is the code that determines where ICP is held.

Will SNSs ever be able to set the ‘minting account?’

You mean when the SNS is created? I can’t imagine that supporting this is on our roadmap, but my guess is that if there is “significant” demand, we could do it (again, not making any promises here). There are probably a bunch of security implications that I have not thought of → it might be hard to do this → my guess is that the demand would have to be “very” significant to overcome the security re-think activation energy.

For the time being, here is the code that sets the minting account.

[skilesare]

@lara

This is actually explicitly not possible. The governance canister prevents the registration of generic proposals that target an SNS canister or the ICP ledger (you can see this here). This should ensure that SNS voters can always detect such important proposals as such. Also, this is to enforce some access controls and ensure they cannot be circumvented by generic proposals.

Perfect! Exactly what I was looking for.

[osman]

Phase-1

Purpose: transparent, auditable, and manageable DAO

Voting proposals: Each proposal is submitted to voting as a “normal proposal”. If the proposal includes a budget request, token transfer from the treasury to other accounts, and an audit request, the proposal automatically receives “critical proposal” status.

The proposal document should also include the option “This bid should be considered as a critical bid”. If xx% of the voters have voted by ticking this tab in the voting, this proposal also gains the status of “critical proposal”. This is how the community’s opinion is reflected, especially in requests for major changes to the platform.

Since the voting conditions for offers with Critical Offer status are different, such offers are put to vote again under critical offer conditions.

Audit: An audit mechanism should also be established in DAOs. Supervisory authority is selected based on the principle of randomness from wallets with 1/1000 or more of the total staked tokens. A designated reward is given to the wallet that performs the audit.

The audit reward budget is created by considering the balance between staking interest, maturity reward and voting reward expenses. (My suggestion is to reduce the staking interest by 1% and allocate the resulting budget as the audit budget.) At the end of one year, the unused audit budget is transferred to the DAO treasury.

As soon as an audit proposal passes the vote in the DAO voting, the wallets, accounts, links and interface pages subject to the audit are automatically blocked from access until the audit is concluded.

The voting result and audit information are sent to the auditor wallet selected with the principle of randomness as NFT, which has a lifespan of 45 days and is automatically transferred to the DAO archive wallet at the end of 45 days at the latest. Auditor within 15 days

1-can do transaction

2- Can return NFT

3-may not take any action.

After 15 days, the NFT with no transactions is automatically transferred to the 2nd control wallet. If the 2nd Wallet does not make a transaction within 15 days, it will be transferred to the 3rd Wallet. As soon as an auditor starts trading on the audit NFT, the life of the NFT is reset and its 45-day life starts over again. If no wallet has last processed the relevant NFT, the transaction is automatically deemed to have been made. (In this case, the vote is considered rejected) and the NFT is transferred to the DAO archive wallet. Here, I conclude that since DAO members do not perform their Supervisory duty, voting has no meaning.

audited decision

1- no error or defect: The audit is closed.

2-partially defective: The decision is implemented by transferring xx% of the amount from the relevant wallets to the DAO treasury wallet. Wallets, wallets and interfaces that were previously closed to access are opened to access.

3- big flaw: The relevant wallets are transferred to the DAO treasury. The relevant links and interfaces are removed from the platform and are removed from use.

[osman]

The purpose of this proposal should be to ensure that the Dao treasure is used in project development. In addition to the ideas stated in the article;
1- Clearly budgeting where, how, how long and what will be done with the funds to be requested from Dao.
2- If the budget allocation is accepted in the vote, the budget should not be transferred to the relevant account immediately. A certain percentage of the budget for the work to be done, for example 30% in advance, should be transferred to the relevant account, and the remaining part should be transferred to the relevant account in the form of progress payment upon completion of the work .
I think it is important to add this idea to the proposal to ensure the survival of the projects.
In fact, while preparing this proposal, the proposal can be matured by taking the experience and opinions of the Definity Foundation budget management unit into consideration.

[yawajon998]

I do not agree:

• If ICP value goes down during work, this can be bad for projects because they take big risk.
• You do not think about how SNS treasuries use their own project tokens. They need them for many things right now, like giveaways and use inside apps, not just for plans that are far in the future.
• And why not ask Dfinity to do the same thing? If we trust Dfinity, we should trust SNS projects too. We should look into projects carefully and choose to put our money in ones we trust.

If someone wants to control what an SNS project does, they should buy more tokens and use their votes. One person’s post on the forum should not be more important than the votes from everyone in the SNS.

[hpeebles]

I think we should keep the solution really simple.

Restricting how much of the treasury can be extracted in a given time period seems unnecessarily complex and overly opinionated since there are valid use cases where a large portion of the treasury should be extracted, for example GHOST sent pretty much their entire treasury to form liquidity pools.

So I still think we should simply make the critical proposals require 2/3 majority to pass and raise the minimum adopt rate from 3% to something like 20%.

This is simple to implement and more importantly, simple to explain to voters. While it would still allow the entire treasury to be withdrawn if 2/3 of the voters approve of it, and I think that is how it should be, if the vast majority of voters want it, then it should happen.

[modclub]

We agree. This seems like the most straightforward and effective solution.

[Seers]

I think we should keep the solution really simple.

Totally agreed.

So I still think we should simply make the critical proposals require 2/3 majority to pass and raise the minimum adopt rate from 3% to something like 20%.

I think that is relative. Our proposal, for instance, passed with 65% (and one could argue that most of the VP knew about it, agreed with it, or even suggested it). If we increase these percentages, they might need to decrease in one year or two.

Another issue is to define what constitutes a critical proposal. We could argue that any dapp change is critical, especially if some of these dapps end up having more TVL than the treasury.

All in all, I still feel better about beginning to add code that allows each proposal to execute with different voting periods (and sometimes enforce them). But I’m ok with your proposal too.

if the vast majority of voters want it, then it should happen

100%. Sometimes we pay more attention to influencers in twitter than to the DAO itself.

[wpb]

@hpeebles

So I still think we should simply make the critical proposals require 2/3 majority to pass and raise the minimum adopt rate from 3% to something like 20%.

I agree your proposal is sensible. Do you think there should be changes related to following for these critical proposals?

[wpb]

@lara

While I understand the concern here, let me also propose a possible counter-argument. I wonder if this is the right question to ask / analyse as it might be that up until now the SNS communities just never had to try to reach a large base of their voters. I think one can argue that this is also a downside of following that proposers sometimes might have to try less hard to really reach the community and promote their ideas.

Fair point. This is uncharted territory for ICP since we have always had following. Perhaps people would be much more actively involved if they were required to vote manually on every critical proposal to received voting rewards. Speaking from my own experience, I don’t think I have ever participated in an SNS vote manually. I don’t have the bandwidth. It’s all I can do to keep up with what is happening in the NNS. At this time is seems like a high risk that SNSs could lose access to their funding stream if the bar is set too high.

@lara

as a summary I understand you propose to lower the bar of measure 2 a bit and just remove the critical proposals from the catch-all “all topics” rather than fully removing following for them.

Yes, it would be exactly the same as the technical implementation of proposal 34485, which removed the Governance topic from the All Topics catch all in the NNS. This is the mechanism by which default following was removed for the Governance topic. Hence, there is precedent that remains in place today.

[osman]

When I wrote my this opinion, I wrote it because I believe that DAOs should provide financial support to their projects. If the DAO does not provide financial support to the project, the DAO has no meaning. The problem here is that the 1-DAO treasury gains the ability to be controlled by the community.
2-find a way to control how and where the budget provided by Dao is used.