like you must be absolutely out of your mind wanting to force transfer largest multisig wallet away from its owners

Just for clarification: 

- The Society treasury is NOT a multisig, but an account existing in the pallet like the treasury is on Kusama Network. Society members have no control over these funds (aka. cannot decide how to discretionally spend them) and the only function of the treasury is to feed the Society pot with some KSM per period for new bidders. 

- The decision to send _part_ (0.2%) of the burned funds to the Society treasury was a community decision, and the community can also stop this decision with a governance proposal. 

- I believe the Kusama burn rate at the beginning was null, and it was decided to set it up to a certain percentage to mimic Polkadot's behaviour. 



Here's a clip of [Adam explaining the concept](https://twitter.com/TheKusamarian/status/1643607730450472967) on AAG. 🥚

Hey Adam,

As I already mentioned, I truly appreciate your dedication to moving beyond mere discussions and presenting a practical solution. It's always refreshing to see a proactive approach in action. 

I believe it would be beneficial to conduct a smaller-scale experiment on this case before fully committing to the proposal. This would allow us to gain valuable insights, assess potential risks, and make any necessary adjustments to the approach. Please have a look at the proposed steps (sent you .doc on Element):


```
Milestone 1: Proposal Preparation and Community Feedback

Task 1.1: Present a new proposal during the discussion phase.
Task 1.2:  Present the working budget, incorporate the research hours spent into the proposal.
Task 1.3: Request a smaller test amount of 100? KSM.
Task 1.4: Align the proposal with feedback from experienced community members like Joe, Kian and Raul.

Milestone 2: Research Expansion and Scenario Analysis

Task 2.1: Expand existing research on staking Kusama Treasury funds.
Task 2.2: Present projected trajectories under different scenarios.
Task 2.3: Go deeper into ideal staking calculations.
Task 2.4: Cross-check findings with developers and confirm the proposed calls
Deliverable 2.1: Comprehensive research report with scenario analysis and calculation validation.
Deliverable 2.2: Completed and revised proposal document, incorporating all tasks.

Milestone 3: Test Case Execution and Evaluation

Task 3.1: Stake the allocated 100 KSM from the Treasury.
Task 3.2: Monitor the staking process and document any issues or observations.
Task 3.3: Analyze the impact of staking on rewards for the rest of the ecosystem.
Task 3.4: Evaluate the success of the test case based on the project's objectives.
Deliverable 3.1: Test case execution report, including findings and recommendations for future implementation.

Milestone 4: Community Engagement and Final Reporting

Task 4.1: Share the research report and test case findings with the Kusama community.
Task 4.2: Gather feedback and address any concerns or questions.
Task 4.3: Prepare a final report summarizing the project's outcomes and recommendations.
Deliverable 4.1: Final project report, incorporating community feedback and suggested next steps.
```



I want to thank everyone for getting involved and providing valuable feedback. I'd like to address all of the points brought up across various platforms all at once.

#### There should have been a discussion before going on chain

First off, this *is* the discussion; the referendum isn't even deciding. Anyone with 3,333 KSM should be prudent enough to wait until this discussion has matured before seconding the referendum by placing the decision deposit down. Also, I have observed that the best way to get people involved in a discussion is to force them to reckon with a real consequence; participation is weak in most discussions without on-chain consequences.

One thing I've noticed, especially around the topic of the Treasury, is that there is a whole lot of talk but no action. Most discussions resolve to "we need to audit projects, be more diligent in selecting spends, and use milestone-based payout." Yes, we need to do those things, but those things are not enforceable and the hivemind continues to approve reckless spends. Rob Habermeier made a tweet recently that mocked ecosystems whose governance isn't tied to an executable on-chain action. I was tired of deliberating without real consequences - at least now we have something to chew on.

If this discussion finds a better configuration then we simply resubmit. And we aren't jamming the track since, as I said above, the decision deposit isn't placed.

#### Staking Treasury funds breaks the assumptions of KSM's tokenomics

Byran Chen in the Kusama Direction Channel brought up this point. Let's explore this a bit. Staking to secure the network assumes:

1. KSM has real value
2. KSM stakers are a decentralized group
3. KSM holders traded economic value to obtain their tokens
4. Malicious validators are slashed and sent to the Treasury (i.e. a place where tokens are no longer supporting those malicious validators)
5. A set of well-behaved, decentralized validators effectively secures the network
6. Stakers are rewarded by fast and well-behaved validators

Bryan said by staking Treasury funds we are breaking assumptions 2 and 4. If you really think deeply about these assumptions and the destiny of the tokens being slashed, we aren't breaking anything by staking Treasury funds.

- The Treasury is an agent of the Kusama relay chain. It trades Kusama's functionality for KSM, thus tying KSM collected from transaction fees to real value as long as those transaction fees are being mostly collected from a decentralized set of users that traded other economic value for their tokens (assumption 3). Ultimately, the Treasury's funds are a fungible pool of all the value traded to pay for transactions on Kusama.
- Slashing funds is to punish the validator and its nominators. Pretending these slashed funds are burned out of existence is silly. Ultimately, slashed funds will eventually get sold on the open market by projects funded by the Treasury (or by people with Kusama tattoos). The value that projects bring to Kusama offsets: the economic damage caused by bad validators and the value lost on those projects selling their KSM.

If one of the validators that the Treasury is nominating is slashed, those funds become liquid in the Treasury once again, decreasing the perpetual revenue the Treasury is earning from well-behaved validators. So the Treasury *is harmed* by a slash. While the Treasury can restake those liquid funds, it certainly won't stake them on the bad-behaving validator. This process is regulated by the nomination pools and can be further regulated through governance if the nomination pools are showing poor judgment.

Essentially, we are trading liquidity that would otherwise be spent to give the Treasury dividends. These dividends will take *years* to produce the same liquid amount. 

#### The purpose of the Treasury is to spend all of its funds, hence the 0.2% Treasury burn every 6 days

This is not a sentiment shared by everyone in the ecosystem. In fact, many believe we should stop the Treasury burn altogether. I've observed that people are far more interested in preserving the Treasury rather than spending all of it.

I think it makes way more sense to sustain the Treasury rather than spend it. Any prudent business seeks revenue while keeping some cash on hand.

#### By taking so much away from the Society, it will no longer be sustainable, especially with Society2 coming out

There are many who agree that the Society doesn't bring any value to the ecosystem and should be totally removed. We are essentially paying for a social proof of peoples' body marking. Aside from the ethically questionable nature of this social game, how exactly does having users tattoo Kusama branding on their body bring value to the network? If anything, it makes Kusama look like a weird cult.

Also, most bids to join the society are very low. I highly doubt you need more than a few thousand KSM to tattoo enough people to play this silly social game. Note: I'm not saying that people *shouldn't* tattoo their body with whatever they want - I've thought of getting a Kusama tattoo myself. I'm just saying that it doesn't bring tangible value to the ecosystem.

It can really boil down to this: if anyone asked for 120,000 KSM to put Kusama branding on 150 people and to maintain a social game of those people proving to each other that they have their tattoos, such a spending request would be utterly shot down.

#### Staking Treausry funds takes away from the rewards for the rest of the ecosystem

Excellent point that I didn't consider. Let's calculate the exact effect (at block ~17,341,000).

- Total staked: 6,930,900
- Total issuance: 13,421,800
- Stake proportion: 51.6%
- Ideal stake proportion: 53.5%
- Inflation rate: 9.74%
- Total staking rewards per year: 1,307,166
- Ecosystem RoS with 10% commission average: 16.97%
- Ecosystem RoS with 15% commission average: 16.03%

If the Treasury added 270,000 KSM:

- Inflation rate: 9.84%
- Total staking rewards per year: 1,321,357
- Total non-Treasury staking rewards per year: 1,269,883
- Ecosystem (sans Treasury) RoS with 10% commission average: 16.49%
- Ecosystem (sans Treasury) RoS with 15% commission average: 15.57%

Overall, this decreases RoS for stakers by ~ half of a percent point (or 2.85% less than current rewards). In other words, if you're making 100 KSM per month on staking, this referendum will decrease that number to 97.15 KSM.

#### Why not have the Treasury make its own pool that's managed by a multisig

That's an excellent idea that could be done in addition to this! The problem is that a nomination pool can only nominate up to 24 validators so there would be a limit to how much could be efficiently staked in that pool (~150,000). Also, a multisig is a less agile solution to changing nominations. By nominating many existing pools, we stay agile in each one individually while decentralized across them all.

Still, I do like the idea of a multisig-managed nomination pool for the Treasury!

#### This is complicated and pointless

Okay Joe, wen Treasury staking pallet ser? We're all waiting :)

Proxies are not that complicated but even so, I'm more than happy to create a thorough tutorial on how to submit a `root` track referendum that changes one of the proxy's nomination pools.

That leads me into a point I'd like to bring up:

#### Parity's monopoly on the runtime

It's so often that developers in Parity make statements like "you can build X that solves Y with a pallet, wow, such WASM." *Clearly* there's a huge leap from idea to implementation with developing on Substrate and the Parity technocracy just loves making such idealistic claims. Thing is, they're the only ones that can realistically build the things they tout, and since Parity is a large bureaucracy with a duty to patch security issues and build far more practical things, the lower priority idea of Treasury staking is kicked down the road indefinitely. **I challenge anyone to put a runtime upgrade on chain in the next 30 days that implements a Treasury staking pallet**. It's not going to happen and we'll all be twiddling our thumbs waiting with false hope.

To be clear, I am very glad that Parity exists and works on constantly upgrading the runtime. But we can't ignore the fact that they are literally the only ones doing it and the barrier of entry to do what they do would require a huge grant, like many millions.

This referendum is a solution that works *right now*, albeit imperfect.


> Okay Joe, wen Treasury staking pallet ser? We're all waiting :) Proxies are not that complicated but even so, I'm more than happy to create a thorough tutorial on how to submit a root track referendum that changes one of the proxy's nomination pools.

A Treasury Staking pallet is completely unrelated to proxies. You just don't need them at all. You can remove everything proxy-related from your call and it will still work. Just create some account names, like `treasury/staking/01`, and zero-pad them to 32 bytes, which is `0x74726561737572792f7374616b696e672f303100000000000000000000000000`, which is `FD149hZKgVRieP5vRiTb3oLGibuZft9JB1c8Wz1Udj1QRVZ`. The Root origin can control any account.

I'm not sure how you get from proxies to Parity and the runtime, since nothing is needed in the runtime now to do your proposal without proxies (i.e. it will work right now). But I don't think a Treasury Staking pallet is just "lower priority", there seems to be a lot of people who think it's a bad idea. And good thing we have the Polkadot Fellowship to take over the runtimes.

Ah, I see what you mean Joe. I did consider creating accounts like you've mentioned and have them controlled by root. The reason I chose to make them proxies is for accounting/ tracing reasons. Someone might not know the accounts created to facilitate Treasury staking and would have to find them with balance transfer tracking which is difficult when thousands of accounts are transferring funds to the Treasury. And if I understand this correctly, indexers would need to hard code these as system accounts to display them on their block explorers correctly which places a burden on those implementers. I could be overstating that challenge though; might be a lot easier than I'm imagining.

I suppose my idea was to treat the Treasury as the only sovereign entity controlled by root. That way there are receipts for transactions made by the Treasury itself. By having proxies of the Treasury, it makes them more explicitly linked to the Treasury. And block explorers already have the infrastructure in place to trace proxy calls to the original caller.

As a data analyst that frequently struggles with Kusama chaindata, I thought this relationship between the Treasury and its own proxy accounts made the most sense for people doing on-chain sleuthing. But I certainly could have been over-thinking it.

I was also thinking an approach like Joe suggested would have been nicer not only because it's simpler as you are already are using root to do `util.dispatchAs` but also can make the addresses more easily discoverable.

Play with the account generation with something [like this](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=01823ed17c17f18eb8432c2f996a9d96).(For Polkadot some day I'll make a referendum to make myself a proxy of a vanity address using [this trick](https://olanod.github.io/keyless-vanity-substrate/demo) ;))

so with a single referenda you plan to render my skin in the game as meaningless as Novogratz Terra tattoo. I think it is up to Society to decide what to do with their funds. Society v2 is about to be shipped out, so take your tattoo if you keen to have your voice.

My understanding is that a lot of spending that should have come from the Polkadot treasury in recent months has been covered by the Kusama treasury because Polkadot hasn't implemented OpenGov yet and their old process is too congested.  Have Polkadot council members not been advising applicants to tap the Kusama treasury instead?  That favor has put negative pressure on the KSM price and drained drained the Kusama treasury.

Our first step should be making a proposal when OpenGov launches on Polkadot for the Polkadot treasury to pay back the Kusama treasury.  That would put positive pressure on the KSM price and also refill the KSM treasury without effecting staking rewards.

Putting a bunch of idle KSM to stake in order to refill the Kusama treasury instead of just asking to be paid back has the effect of transferring Polkadot expenses into a stealth tax on Kusama's token holders (depressed price) and stakers (less KSM in staking rewards).

Agree with the friend Kekose. As stated in [the forum](https://forum.polkadot.network/t/polkadot-and-kusama-shared-economy/1723?u=olanod) I would even go further and create a social(or coded) contract where Polkadot sends DOT to Kusama not once but say 10-20 times over the next 10-20 years, a decreasing amount following some curve basically acknowledging the important role of Kusama as the innovation hub where most projects that will ever become something start their journey.

I cannot speak for other council members, but I can say that when me and my team advice proposers we explain all of the options available for funding, the differences and the limitations on the models for them. For Polkadot, it is true the Council is not acting fast enough, or there are too many submissions for the level of time council members can commit to review and vote, and this has delayed things a bit - some proposers do not want to wait or prefer to start on Kusama: our advice is always Kusama for more experimental/innovative code and "out of the box" projects, or for Kusama integrations, Kusama events or any project focused on this network: some teams alternate between treasuries as they develop and integrate both networks. The community still votes on these proposals if they go to Kusama: it is not a unilateral decision by council members to give funds if the proposer decides to go to Kusama.

Hi Adam,

Just want to say thanks for the elaborate report and time put into testing by using chopsticks to validate your proposal with such exhaustive calls - Chapeau!

Also thanks for being among one of the chosen pool operators presented in your proposal - I tried to be as unbiased as possible in my words below.

I’m voting Aye (my thoughts are solely on this proposal and what is up to vote now). 

There are lots of good things, i'll try to enumerate just a few that come to mind:

1. This proposal was created by someone from the community that is around long enough to have some credibility and has already demonstrated a few times that cares about this Canary.

2. The proposal uses the tools and calls available today so it can be experimented tomorrow and results analyzed by the next day. There is no need for further changes or waiting a few weeks or months for a better alternative, I’m sure it will come, but there is no wrong in trying things here.

3. I’m not a member of Society so I’m neutral in terms of using Society funds, but reading previous comments from Raul and Kian - long old members - I think there is some green light and space to put these funds up to good use.

4. Funds presented are massive, but they're not being allocated to any specific project/team, they are just being staked and returns going straight to the Treasury - more Treasury income will promote teams to present their best side and best ideas.

5. Selected pool operators are as Adam pointed out community members and people that are also here long enough to aim for the success of this all thing we work everyday. It's a group of decentralized people with different ways of managing their pools and selection criteria. If at some point anyone in the community dislikes the operation of a pool is free to call it publicly out and ask for changes. Validators assigned in these pools promote decentralization of the active set and are the same ones that people trust and nominate today.

6. If returns go drastically down after the amount presented here gets bonded, I think people will just have to find better ways of using their tokens by spreading them out through the eco rather than just staking. This proposal could end up indirectly revitalising a few parachains and promoting crowdloans again, who knows?!

7. Last, there will always be a better way of doing things, the next proposal/idea will always be better than the first one, that’s how things evolve, but until the next one pops up, I think **it is crucial that we as a community are not afraid of experimentation in this Canary we call Kusama** from proposals that aim for the common good triggered by community members.

—

Disclaimer: TurboFlakes operates Pool #12. The pool is fully automated and nominates 24 good performant valid validators from the Thousand Validators Programme every era. More information can be found [here](https://one-t.turboflakes.io/#/kusama).

—

Best,
Paulo



It probably would have been good to have a discussion phase before proceeding to a vote. 



Such an interesting proposal. Thank you Adam for your work! 

I'm not quite sure if this is the best solution to the problem but it is an experiment I can get behind, you have my vote sir.

I love Adam's proposal here with a very detailed plan and will be voting Aye on this 100% when some of the points mentioned here will be applied, such as the discussion phase for a full week as per the norm and maybe testing with smaller amounts first to see how things go and if this plan could be successful. 

Because I'm in support of this (except for the points mentioned above), I'll abstain from voting this time + I don't know if anybody will add a 3,333 KSM decision deposit given all the comments that took place already and Adam likely knows this too so I look forward to the next one.

I find this proposal really interesting and also appreciate the effort put into the research and the presentation of practical solutions. I think that for a determined period of time, it would be a good use of the Society treasury funds (side note: I never realised there was a pot AND a treasury in the society pallet - I was only able to check the pot on Polkadot.js) to be staked  and a good way for the community to: 

1. participate in the shared security of the network, 
2. experiment with collective decision-making on a tangible manner (decide on nom pools) and 
3. get an extra funding funnel for the treasury. 

I think what is left in the Society treasury should be enough to continue experimenting. Kusama is a network that allows us to experiment like this: and in any case this particular experiment can be cancelled if the community thinks it should in the near future - returning funds to treasury via governance. 

For the Polkadot.js Apps bug you found with regards to calculate ideal staking proportion: I can open an issue on the repo if you want?
#
**On subsequent steps if this proposal is approved:**

_“As being discussed in this forum post, we propose a custom runtime upgrade to change the spending tracks from general spending categories to topic-based spending tracks and restrict spending bandwidth.”_

I am wondering if you are in contact with any of the devs working on release cuts and publication to check on the process, make sure all is taken into account, etc? 

PS: it would have been nice to discuss this before submission.

Our vote against this proposal is based on the following two concerns:

1. We believe that a public discussion round should have taken place before starting a vote. It is crucial for the ecosystem to have an opportunity to express their opinions and provide feedback on proposed changes.

2. While the idea of returning a portion of the funds to the society might be a viable option, there should be a discussion about how much the society needs to continue, members and non-members should be able to come to a conclusion. We believe that retaining only 4,000 KSM are not sufficient to ensure the sustainability of the society game since with society2 there will be no more member limit.

Thank you for choosing us for one of the nomination pools, we appreciate it. 

In response to the feedback given on this referendum, I've decided to start pursuing a simpler, scalable, more elegant solution for Treasury staking. This new solution is more agile, robust, and will not require `root` track referenda to manage. It also doesn't use nomination pools which are clearly not ideal for staking Treasury funds.

In short, here's my plan:

1. Thoroughly vet users to come up with a solid group of `n` number of staking experts, where `n` is an odd number.
2. Create a multisig account with those experts and a threshold of `(n + 1) / 2`
3. Create a `pureProxy` of that multisig account of type `Staking` and configure its controller to be the multisig account
4. Request a much smaller amount of Treasury funds via one of the spending tracks to go directly into the `pureProxy`
5. Actively manage nominations via the multisig and set staking rewards to go directly into the Treasury.

If you would like to be considered as a signatory of this multisig, [**follow this link to the application**](https://docs.google.com/forms/d/e/1FAIpQLSfIRMHsRCM8Fwpu_iSoHqacyz7XEpNT6f4uTElxap87H7-a5g/viewform?usp=sf_link) or fill out the embedded form below:

<iframe src="https://docs.google.com/forms/d/e/1FAIpQLSfIRMHsRCM8Fwpu_iSoHqacyz7XEpNT6f4uTElxap87H7-a5g/viewform?embedded=true" width="640" height="1522" frameborder="0" marginheight="0" marginwidth="0">Loading…</iframe>

> You don't have to use proxies to do this

Exactly :). This is pointless and adds lots of unnecessary complexity to the proposal.

> Before we get into projections, I want to address a very annoying bug in polkadot.js that probably hurts the ecosystem's marketability. 

For reference, this is being tracked [here](https://github.com/polkadot-js/apps/issues/8174).

--- 

* The amount of funds stored in the society is a bit preposterous to me and should be utilized for something. I am myself part of the society, and am in favor of revising the amount of funds that are moving to the society treasury. 
* I am not entirely convinced that the treasury funds are meaningful to be staked. First, all of the extra staked amount will reduce the staking reward for everyone else. Moreover, it is questionable to say that these extra tokens add anything to the "security" of the network, because if the get slashed, the mostly end up being back in the treasury. That being said, given the low liquidity in the treasury, what it can do is to move its funds to a separate account, to prevent them from being burnt. 
* I am very curious for the treasury itself to open a nomination pool, and then handover its `nomiantor` role to a multi-sig owned by the parties you are suggesting. This will allow for more or less the same outcome, and won't need so many pure proxies to be created. Moreover, others can follow the strategy of the "treasury pool" by simply joining one pool. Even further, a contract can be crafted to make the treasury pool follow the behavior of the aforementioned pools, read: [https://forum.polkadot.network/t/nomination-pool-controlled-by-a-smart-contract/2436](https://forum.polkadot.network/t/nomination-pool-controlled-by-a-smart-contract/2436)

Some legacy context:

- Treasury Burn was disabled intentionally from the start on Kusama. 

- Treasury Burn was reintroduced to match Polkadot configuration. 

- Part of the treasury Burn was directed to Society (verifiable on GitHub), voted by community.

what would be the implications to make treasury burn null for the network? I am wondering if this could also be a temporary solution, by my conversations with Emiel from Polkascan (thanks for the input Emiel!).

Hey Adam,

I appreciate the well presented case and I look forward to seeing the community feedback and thoughts on the matter. I will abstain from voting on this proposal since I am mentioned in a nomination pool operator role. 

I appreciate the effort put into the research and the presentation of practical solutions in this proposal. I would recommend conducting an audit on scheduled calls by a Parity employee to ensure the prevention of any unforeseen circumstances. I have to agree with others that it would be better if this proposal went through a discussion phase first.

My Nay vote is for the reasons below:

1. I do think there are other avenues for preserving the Kusama Treasury that need to be investigated before implementing the above tweaks at the core of the network.

2. I think we should encourage individual recipients of Treasury fund to stake some of their payouts to support the collective effort of maintaining the Treasury and the network (i.e put their monies where their mouth+bread & butter are).

3. I think that members of the Kusama community might need to define their own rationale on how they want the Treasury funds spent, thinking about sustainability for themselves and others in the long term, rather than just focusing on how they can save/prevent the funds from being spent (i.e hoarding) or how they can get most of their mates/friends/supporters to get funded (i.e politics).

Thank you for your time. :)


Despite I agree with the principle and obviously note the effort Adam put in this proposal, I am voting Nay because of the usage of nomination pools and the unnecessary complexity of the system set. 
Claiming treasury rewards would have to be made by a proposal each time, nomination pools are not fit for this purpose.

I would rather see funds delegated to 1KV addresses.

If you examine the call, claiming rewards in this manner is automated by the scheduler and it occurs every 86,400 blocks.

But after this discussion I'm inclined to agree that it is an overly complex solution.

Send a batch of dispatch calls.
Unlike `batch`, it allows errors and won't interrupt.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatch without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

# <weight>
- Complexity: O(C) where C is the number of calls to be batched.
# </weight>

#145 Kusama Treasury Staking Configuration