During the weekend some important ideas came up regarding **1. nature, composition and duties of the Council** and **2. number of validators in the network**. This article summarises the main ideas to continue with the conversation **in order to take action.** 

**1. Council composition and structure:**
	
Regarding plans for Council seat cap and composition, it was suggested to move forward with two measures:

1a. Giving the `ElectionsPhragmen.DesiredRunnersUp` constant a higher value in the next runtime upgrade. It is said to allow more visibility to candidates. Although this would have **no implications for the decision-making process** of the Council, this would allow a **higher number of runner-ups to be visible**. 

1b. Increase the number of **Council members from 17 to 19**: given the number of runner-ups and the increase of all other metrics, the Councillors number increase is suggested for the Council to be more representative of passive stakeholders. 

1c. Some suggestions in the governance module were made in Kulupu that raised suggestions in Kusama, in particular **lowering the reject origin to 1/5**. The direct result is that it would be easier to reject treasury proposals, limiting Council abuse. A second suggestion included addressing **the separation between Council and Tech Comm**.

1d. Work on **background and interviews by Councillors** - suggested as a bounty, this consists on written statements / semi structured interviews with (candidate) council members covering: introduction, representation, plans/vision/ambitions, etc.

1e. Open a proposal for **participation lotteries** to be developed.

**2. Validators, number and threshold**

As an agreement after the 500 validators milestone report, it was agreed t**o revisit the metrics after the 600 validators milestone was reached**. However, a good point was raised during the weekend regarding validators: A validator slot can now be secured for  approx 4300 KSM. The decrease of this value as we increase the number of available slots tells us that **the speed of growth is not in line with the stake evolution**. 

The Council must keep an eye on this to either: 

2a. Stop the scheduled increase once the report metrics change, or stop the schedule increase if the minimum stake needed goes below a decided threshold. An idea is also to stop the increase to allow validators to reorganise and nominators to renominate.  In order to decide what should be the ideal threshold, Emiel proposed **this to be 30% of the avg staked value**, which reflects the current value today. 

2b. While we monitor/stop the increase for he min.value to reflect the 30% of avg staked value, we should keep in mind the capability of validators to make a profit: a small min.value would allow small validators to start validating, but if we increase the number the profit will reduce.

A suggestion to action:

- Calculate 30% as minimum and keep it in the current value, stoping the increase if it lowers to give validators and nominators time to reorganise.
- Report on the speed of the increase of value, depending on new stake. 
- Advocate to increase stake in place

Please add your POV for all ideas using the number on each, making sure we cover all topics. 

- There were discussions about the Council and the number of validators in the network.
- For the Council, they talked about increasing the number of members and making it easier to reject treasury proposals.
- They also suggested having written statements or interviews with Council members.
- They talked about opening a proposal for participation lotteries.
- For the validators, they discussed the minimum stake needed and the speed of growth. They might stop the increase if the stake goes below a certain threshold.

#250 Some important ideas discussed in the last days regarding Council composition and validators