The proposal aims to upgrade Kusama's runtime to [v9340](https://github.com/paritytech/polkadot/releases/tag/v0.9.34): more information about Gov2 can be found in the release notes.  **Runtime**  \[S\] ✅ audited [#12310](https://github.com/paritytech/substrate/pull/12310) Low - Asset pallet: support repeated destroys to safely destroy large assets  \[S\] ⏳ pending non-critical audit [#12730](https://github.com/paritytech/substrate/pull/12730) Low - Allow alliance fellows to give up voting rights  \[P\] ✅ trivial [#6326](https://github.com/paritytech/polkadot/pull/6326) Low - Add collectives as trusted teleporter  \[P\] ✅ trivial [#6366](https://github.com/paritytech/polkadot/pull/6366) Low - OpenGov: Proxy definitions  \[S\] ✅ trivial [#12808](https://github.com/paritytech/substrate/pull/12808) Low - Bounties use SpendOrigin  \[S\] ✅ trivial [#12610](https://github.com/paritytech/substrate/pull/12610) Low - Non-interactive staking  \[S\] ✅ trivial [#12842](https://github.com/paritytech/substrate/pull/12842) Low - OpenGov: abstentions  \[P\] ✅ trivial [#6390](https://github.com/paritytech/polkadot/pull/6390) Low - Allow Root with OpenGov origins  \[S\] [#12848](https://github.com/paritytech/substrate/pull/12848) Low - Add `with_weight` extrinsic  \[P\] ✅ trivial [#6372](https://github.com/paritytech/polkadot/pull/6372) Low - OpenGov: Kusama tweaks   Proposal hash: `0x0debc0e862468363f53cf1ea4d451ec2fdfc4aeb37a3189354df9597636c55b9`  Note this proposal is submitted with `set_storage` call, not `set_code` call (more info on why `set_code` won't work can be found on [this post](https://polkadot.polkassembly.io/motion/306)).  Preimage:  ![](https://i.ibb.co/bbKw1tx/Screenshot-2022-12-07-at-09-53-08.png)  You can review the hash and changes in the release notes and use `SRTool` to verify the proposal hash - make sure to vote at your convenience! This proposal is submitted as an **external motion**: meaning after the Council vote, the community will need to vote on the proposal in the referenda queue.

Runtime v9340 Upgrade On Kusama: Fixing OpenGov Parameters and more!

With OpenGov up and running on Kusama, the current auctions [schedule](https://kusama.polkassembly.io/motion/438) suffers an enactment issue: all pending auctions won’t enact successfully, although scheduled, due to a `BadOrigin` error: [https://kusama.subscan.io/block/15523200?tab=event&&event=15523200-16](https://kusama.subscan.io/block/15523200?tab=event&&event=15523200-16). This is because with OpenGov, an auction needs the [`AuctionAdmin` origin](https://github.com/paritytech/polkadot/blob/v0.9.32/runtime/kusama/src/lib.rs#L1245) to be enacted successfully, but the original auctions for LP25 had the origin of more than 3/5 Council. ```  [    [      15,724,800    ]    [      {        maybeId: 0xf31cf33afabfc39818c20e858c4ceded9bf70cb3d29d460adc468af33853873c        priority: 0        call: {          Inline: 0x4800e2a5010068        }        maybePeriodic: [          100,800          2        ]        origin: {          Council: {            Members: [              13              19            ]          }        }      }    ]  ]```With this new proposal we aim to include the last auctions on LP26 + the ones what were not enacted on LP25, now to be included on LP27. A new calendar for auctions will be proposed soon in OpenGov, but since this one is a legacy proposal, approved by the community and not working due to a problem with origins, It would be ideal to fast-track to enact ASAP. - Proposal Hash: `0x3f303aa09336575dd393dd38f26b1db6fe46eb8fb082b6abae93aa2bf79cd0e3` - Primate submission: [https://kusama.subscan.io/extrinsic/15580971-7](https://kusama.subscan.io/extrinsic/15580971-7) - Image can be found [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x1804081d052bd1e9469fc73e572f6019b15ab507656fa8b34937ee212544eb877c5c6dd0da0000000001c089010004000000004800e2a50100681d05337955059e29e88811a9ffbbcdc33a57bb70ce142b89f935fbeb795507e3f2482043060001c089010002000000004800e2a501006c)

Fixing the Last Auctions From The Auctions Schedule - Kusama Network

This proposal (hopefully the last one for Council) is now up for vote on Kusama:

With the [v9320 runtime upgrade](https://kusama.subsquare.io/democracy/referendum/244), an issue with migration appeared: the migration did not work for preimages submitted before the upgrade as well as for proposals approved by the community and on dispatch queue. This included:  
- [Genshiro's proposal](https://kusama.subsquare.io/democracy/referendum/246) to swap slots, already approved by the community and on dispatch queue.
- [Kintsugi’s proposal](https://kusama.polkassembly.io/referendum/242) to open an HRMP channel with Statemine, already approved by the community and on dispatch queue.

In order to make sure the approval by the community is held as true, we aim to vote again on these two proposals to have then enacted as decided by the community, in time. For this, the proposal is composed by a `batch` call including: a `forceOpenHrmpChannel` (for Kintsugi and Statemine) with a `forceTransfer` call from treasury to pay for the cost of the channel opening, and a `registrarSwap` call (for Genshiro). We aim to vote this ASAP to pass it to vote. Preimage is submitted. 

- Call hash: `0x83c439b8b621a3507c90c8a3ebd0c4b3d76962f853e1f11858e665aeafaeac14`
- Call data: `0x1804140402006d6f646c70792f747273727900000000000000000000000000000000000000000070617261e80300000000000000000000000000000000000000000000000000000b00a0724e18093c07e80300002c080000e8030000009001003c072c080000e8030000e8030000009001004603b2080000e80700004603e8070000b2080000`
- Composition can be found [HERE](https://i.ibb.co/b6VZ48J/Screenshot-2022-11-23-at-15-29-48.png) and [HERE](https://i.ibb.co/pn03Ssm/Screenshot-2022-11-23-at-15-29-56.png).

Please vote at your convenience! This is submitted as an external motion: after Council approval the community will vote on this. 

Fixing the disappeared approved proposals (by the community) on relaychain from Genshiro and Kintsugi

This is a techincal committee proposal whose proposer address (FhLMxxkXxfgRRnv8hyRbNkpUMZ9umASMsRmKpZruVayaqhL) is shown in on-chain info below. Only this user can edit this description and the title. If you own this account, login and tell us more about your proposal.

External Motion: Approval of Treasury Proposal 227 - KAGOME C++ implementation

Hello everyone, I am Hitesh from Describedot. We create educational videos and weekly updates around the Dotsama ecosystem. We started this channel about a year ago and we have already published 34 videos on our youtube channel. Our weekly viewing growth had been over 28 percent which led us to approximately 30,000 views in a year. Recently we’ve also received great support from the Council Members of Polkadot and Kusama through tip endorsements. We are really thankful to the community members who supported us and assisted us in making great content.

Just last year we learned that people want to know about governance, about networks but they don’t have any resources to walk them through it. We decided to create basic videos during our early days and this has helped users to explore the Polkadot stack. They expressed their gratitude through likes and comments on our videos. Our main focus is to teach the Polkadot stack as well as governance in layman's terms to the Hindi audience.

Our first milestone was covered by WagMedia but we are looking to continue the work with a spending proposal. 

You can learn more about our proposal from the document. Let the community know if you have any questions. We are happy to answer them

[Describedot](https://docs.google.com/document/d/1vnweYrk-ooQqfbha_EJUy9qYx3KDN3mk6PZVM7k0UPM/edit)

Treasury Proposal: Production of Dotsama ecosystem tutorial videos for Hindi audience

This is a techincal committee proposal whose proposer address (F2i6trfXqFknbgB3d9wcd1X98WWdLLktmFtK8Beud75bjTW) is shown in on-chain info below. Only this user can edit this description and the title. If you own this account, login and tell us more about your proposal.

Statemine Runtime Upgrade to v9320

Full proposal with UI screenshots and all details can be found here: [Link>>](https://docs.google.com/document/d/15rnlNk7eka984UXmfNk0Mkdkf94jL1m3aWS8IeedgyY/)

Twitter thread/feedbacks: https://twitter.com/RemarkPunks/status/1587922570828951553

------------------------------

**Summary**

KusaMint is a development kit for NFT artists, collection makers and the whole Kusama community in general. It provides different tools to mint and manage NFTs with ease.

Our goal is to make NFT creation easy for people who don’t have programming skills. Let anyone mint advanced NFTs with an accessible UI which in return will expand the Kusama NFT community with more talented artists and collectors who were scared by the complexity of mints before.

Currently KusaMint is adjusted for RMRK 2.0, but as development continues, it will scale to RMRK X.0 and other protocols operating in Dotsama.

--------------------------------

**Features**

- ### **2.0 NFT Minter**
An easy to use UI that opens a whole new set of possibilities to new users. The minter will constantly expand its functionality and applications as development goes. 

Currently you can create NFTs with multiple types of resources:

1. **Base resource (Parent)** - the main “Base” of your composable NFT. Child resources will be equipped onto it.

2. **Slot resource (Child)** - these resources allow one NFT to be added on the other one. This can result in NFTs with “equipment”, art with multiple layers, different effects and a lot more depending on the user's creativity.

3. **Common** - classic, non-functional resource. 

Moreover, our Minter allows to:
Create Soulbound NFTs
Inherit metadata from other NFTs
Mass-mint multi-resourced NFTs
Set royalties and royalty receiver
Mint directly to another wallet or NFT
Replace and update resources
Create and manage your base

- ### **Snapshotter**

Create collection snapshots in a simple and comfortable way to get a list of every NFT with its holder details (csv/json)

1. **Lite**-  NFTs & Owners 

2. **Advanced**-  NFT with details & Owners with identity

- ### **Notification Bot Factory**

In a few clicks you can create a sales bot that will read remarks and track your collection sales and floor prices. 

Configure your own bots on all the popular social media: Twitter, Discord and Telegram.

-----------------------

- **Details**

Full proposal: [Link>>](https://docs.google.com/document/d/15rnlNk7eka984UXmfNk0Mkdkf94jL1m3aWS8IeedgyY)

More information about our projects: [Link>>](https://canarys-nest.gitbook.io/ultimate-canarys-nest-wiki/ecosystem/canarys-nest)

**First Milestone:**

- RMRK 2.0 NFT Minter
- Snapshotter
- Notification Bot Factory
- Full UI design
- Integrated Polkadot.js/Talisman Wallets

**Requested Amount:** 1493 KSM/48800 USD (Coingecko data on 2nd of November 2022)

**Total team hours:** 1400 Hours

Costs detalization: [Link>>](https://docs.google.com/document/d/15rnlNk7eka984UXmfNk0Mkdkf94jL1m3aWS8IeedgyY/edit#heading=h.wogmmcdsnfi9)

We are glad to see feedback on proposal as well as suggestions for extra functionality from the community and hope that this development kit will be useful for many creators in the space.



KusaMint - A toolkit for creating/managing NFTs on Kusama

<img style="display: block; margin-left: auto; margin-right: auto;" src="https://luckyfriday.io/wp-content/uploads/2022/06/lucky-friday-logo-full.png" alt="" width="300" height="49">
&nbsp;
The Lucky Friday team seeks funding to provide RPC services for the Kusama and Statemine networks. We are well established within the ecosystem, operating numerous geo-diverse validators, collators, miners, and vaults on Kusama and Polkadot.
&nbsp;
Our team intends to provide RPC services at our SOC 2 Type 2, CCSS-compliant facilities, co-located on dedicated bare-metal servers. We are investing significant capital upfront, believing we can offer reliable and secure unmetered service to the community at a fixed and reasonable cost.
&nbsp;
Our decades of data center experience &ndash; and desire to encourage ecosystem growth &ndash; means that we recognize and are concerned about the risk of centralization happening due to the haste of quickly turning up nodes in AWS, Google Cloud, and others. Hetzner has already begun shutting down crypto-related activities.
&nbsp;
We desire to leverage our high-performance, high-availability infrastructure, and scalability to support the Dotsama ecosystem by providing the enterprise-level connectivity needed to serve an ever-growing userbase and support influential applications like Polkadot.js, Talisman, PolkaGate, Nova, and more.
&nbsp;
The full proposal (<a title="Lucky Friday RPC Proposal &ndash; Council Submission" href="https://docs.google.com/document/d/1sNh6kpdXcW0ZJ1ta9rjFtYQ0DZVg7TOBUepJco5LbWk/edit" target="_blank" rel="noopener">available here</a>) was posted for discussion (<a title="Lucky Friday | Cost-Effective Proposal for High-Performance Bare-Metal RPC Nodes" href="../post/1934" target="_blank" rel="noopener">post 1934</a>) on November 4, 2022, and has received very positive feedback, with 21 likes and 0 dislikes.
&nbsp;
As outlined, we seek initial funding of $11,200 (402.95 KSM based on EMA7). Upon successful completion of milestones as set out in the proposal, we will report on our undertaking and provide details on load tests. We would then further engage for monthly recurring costs of $14,920 (requested quarterly).
&nbsp;
Due to the extreme nature of recent market volatility, we understand that the requested KSM may fall short or exceed the dollar amount needed. If we fall short, we would like to include this amount in our following proposal to continue RPC service. If we are in excess, we will return the balance of funds to the treasury.

Lucky Friday | Cost-Effective Proposal for High-Performance Bare-Metal RPC Nodes

Encointer seeks for financing of its planned activities for the remaining time of its current common-good parachain lease, split into two proposals. The first part of the funding has already passed as [Motion 510](https://kusama.polkassembly.io/motion/510). The current proposal is the second of two and shall cover the funding from beginning of October to the end of December 2022. Encointer’s common good lease lasts until end of lease period 25, which is currently expected by Dec 12th 2022. Please also consider our [request for common good lease renewal](https://kusama.polkassembly.io/post/1900)

The amount of the proposed treasury spend is CHF 257’500 = **USD 261'491** 

Encointer has onboarded as a common good parachain on Kusama on Jan 9th 2022. Please find our earlier progress reports here:
1. Our recent [treasury proposal](https://docs.google.com/document/d/1eTyZGCTCzo7ZGonVtAmJmc5QYYI0qYHab6z8w56B_F0) includes a detailed report on what we have achieved until June 2022 and what our plans are for the future
2. Our [delivery report](https://kusama.polkassembly.io/motion/510#3f6f0d94-639f-49ec-a0ee-1f4ace1a37c8) on above treasury grant updates the information with achievements in the June-Sept 2022 period
 
The main focus of Encointer is currently:

* to grow its Zurich community in order to prove the viability of its protocol and implementation as well as its economics with a pioneer community.
* to onboard new communities around the world, especially in less developed regions in order to follow its vision.
* to integrate with other parachains in the DotSama ecosystem for sybil-defense, inclusivity and one-person-one-vote democracy.

As a common-good, Encointer has no way to promise any return on investment, so the project relies on grants and donations.

See our [Proposal with full details](https://docs.google.com/document/d/18J6qN0vRNjCpII4BAgitjav0O2JbgV6vCvsKfdQGkFg/edit#heading=h.3mhoboeg6pv8)



Encointer Growth Treasury Proposal 2/2

Runtime v9320 Upgrade On Kusama Network

[**Motion 568**](https://kusama.polkassembly.io/motion/568) by a team of Polkadot Ambassadors, aiming to put forward the creation of a **Spanish Content and Event Production Bounty**  and create a mechanism for both Spanish content and events with a focus on speed, effectiveness and control for content audits. The objective of this bounty is to reward the community's content creators for their efforts in creating content in Spanish, as well as to ensure that the content created is of high quality and kept in line with the needs of the ecosystem, incorporating defined criteria for each area of assessment and allowing the submissions process to scale. Additional information on the budget, management of the funds and mechanism can be found in [the bounty proposal](https://kusama.polkassembly.io/motion/568). 

Please make sure to review and vote! 

Original bounty Proposal and contextual information can be found [HERE](https://kusama.polkassembly.io/bounty/16). 

Spanish Content and Event Production Bounty

Extending Encointer's common good lease by 48 weeks

Dear community,

The Proof of Chaos (formerly Governance Participation Rewards) project incentivises voting to decentralise Kusama. We reward referenda voters with NFTs and build out tools to increase governance participation. [Our website](https://www.proofofchaos.app/)

Thank you for supporting the project thus far!
![](https://i.ibb.co/qYKrW5K/download.jpg)
![](https://i.ibb.co/Kj2xxt5/newplot-17.png)

We would like to give you an update on what we have been up to over the past 3.5 months and hope to be granted additional funds for continued development of tools that improve voter participation and make the project more fun, fair and engaging.

To achieve this goal we would like to onboard two great developers ([niftesty](https://twitter.com/niftesty) on frontend / next.js & Thomas on backend work) for fixed term contributions: 40h/month. They have built our current website and their focus will be to build it out further. I (Gabriel) will be scaling back a bit on the development side and focusing on operations a.k.a. the rewards themselves. My mission specifically will be to make the rewards more engaging and work on utility use cases.

With a focus on increasing the value of our collection(s) we aim to boost our revenues and get to a self-sustaining level faster. We are also working on more revenue streams to ensure more predictable and constant income.

A large chunk of the funds is for past project management expenses that we have not been able to cover with our revenues. While I (Gabriel) always ensure that we have enough funds to pay everyone else involved with the project, I made the deliberate decision from the start to align my interests with that of the project: meaning I should only be rewarded if the project is successful.
 
Rather than asking for payment upfront, I do the work first and only ask the treasury to help out when our revenues fall short. Through this structure I of course take the risk of the community not deeming the project worthy of additional funds and thus I am incentivized to ensure that the project continues to perform well. At the same time the community only pays for what they get. For transparency I would like to highlight that I have increased the hourly rate to 80 USD (up from 70 last time). This is the rate that the other developers involved with the project are also charging and thus I hope you find the change appropriate.

Kindly take a look at the [proposal](https://docs.google.com/document/d/1cMIzdxSd1Tf9T5KZvVLQfyvn4gxLSuCKGl7JXbOKaoo/edit?usp=sharing) and what we are looking to build with the extra funding. We appreciate any and all feedback.

You can find the post up for community discussion [here](https://kusama.polkassembly.io/post/1896).

Further funding for Proof of Chaos

I'm [SrSlayer](https://twitter.com/SrSlayer_), Polkadot & Kusama Ambassador.

A few months ago I did a test to encourage learning about the blockchain. This experiment turned out to be a success so we want to make it something formal and constant.

This proposal seeks funding for the creation of “Polkadot Forms”, a series of forms and tests, both in English and Spanish, that will allow the community to learn and test their knowledge in a dynamic way. Each form will deal with a specific topic of the Polkadot and Kusama ecosystem and will be distributed weekly during the months of November, December and January.

The goal of these test sets is to keep the community active in learning about the Polkadot and Kusama ecosystem and motivate them using a healthy and positive contest dynamic. All this to create a formed community and appeal to new users who want to learn in an original and fun way.

You can see the full proposal [here](https://docs.google.com/document/d/14q40d19SVQCyyLPFGdpS5ARJ6qh668YlgujI9RTgcrw/edit?usp=sharing).

Further community feedback may be found on this [tweet](https://twitter.com/SrSlayer_/status/1580544411661791232?s=20&t=IHaPLGeaAxt3eB7RI_H7Vg).

Original post discussion can be found [here](https://kusama.polkassembly.io/post/1883).

Teach Polkadot & Kusama knowledge through a Forms Quiz

I am [Ishita-](https://www.linkedin.com/in/ishita-sri/) founder of [PolkaSafe](https://polkasafe.xyz/). My background is in engineering and finance and for the last two years, I’ve been working in the crypto VC space. 

Over the past few months, I became active in the DAO ecosystem and as I explored the Polkadot and Kusama ecosystems - I learned that managing funds via a Multisig is a major pain point for the communities building in the DotSama space because of the lack of a user-friendly Multisig UX. In order to facilitate DAO growth, my team and I are building PolkaSafe on top of Polkadot {.js}'s security backbone while improving all of its current drawbacks.

### Short description 

PolkaSafe will be building a user-friendly Multisig wallet UI for the Polkadot and Kusama ecosystems. With the mission of bringing digital asset users closer to the Dotsama ecosystem and enabling them to safely manage and transfer their tokens, we are focusing on building a product that will provide a great UX for users to interact with the Multisig feature built-in Polkadot.js

![](https://i.ibb.co/RhWVcmx/Screenshot-2022-10-11-at-11-57-20-AM.png)

Read the full proposal [here](https://docs.google.com/document/d/1TJyqo9Py3Tv_N9nw3D1Ggpkxk0ZfHuT9NnnIwMdv1pU/edit?usp=sharing)




Proposal: PolkaSafe proposes to build  a user friendly Multisig for Polkadot & Kusama ecosystem

## Description

The goal of this proposal is to fund adapting BrightTreasury to reflect the Governance 2.0 changes on Kusama. Both governances will coexist in one version of the app, with clear indication of the governance version related to each mechanism.

Project Link : https://treasury.bright.dev

BrightTreasury is a standalone web application along with a PWA representation that allows performing basic actions on the Treasury module of Polkadot and Kusama Substrate networks (with a potential to support any Substrate-based network with Treasury module). It allows a more intuitive and lightweight flow of submitting proposals as well as an overview of the Treasury related actions.

Our focus is on the regular user’s actions rather than the council perspective for this first release. We want to attract more professionals who could contribute to the community with their ideas and skills but at the same time may not be as fluent in blockchain customs and terminology.

## The team behind it

Bright Inventions is a team of over 70 developers, project managers, UX/UI designers and operations specialists - experts in mobile and web applications, systems integration, IOT devices and Blockchain platforms.

We believe that building a software product is about people working together in a collective way. By offering complex support – mobile and web development as well as IT consultancy we try to eliminate roadblocks towards engaging clients as partners at every step of the process.

We support startups, digital agencies as well as medium to big businesses. We cooperate with startups, accelerators and incubators. Whatever the client profile is, we always aim to establish a satisfying partnership for both sides. Since 2012 we have built software for more than 40 businesses worldwide.

The BrightTreasury team currently consists of:

Łukasz Kuderewski - fullstack developer He is an optimist, always willing to learn new things. Mechatronics engineer who fell in love with programming. He has always been interested in a holistic approach to programming problems, which is why after working as a frontend, he is now fulfilled as a fullstack.

Robert Koprowski - fullstack developer, blockchain specialist He is an experienced and ambitious blockchain enthusiast. Graduated from the University of Edinburgh, he lived in various locations around the world to settle now in Gdańsk. Originally a Backend Developer who decided to extend his skills and become Fullstack Developer, always trying to learn something new.

Pavel Jankoski - fullstack developer. Communicative team player interested in finding solutions to complex problems. From the very beginning he started working as a fullstack developer and tried many different frameworks which makes him a fast learner eager to uncover new technologies. He enjoys contributing in flexible environments that allow him to explore new cultures, together with colleagues from different countries.

Joanna Cieszyńska - a product designer. She’s passionate about user-centered design and likes to pay attention to the accessibility aspects of it. Just wants to make sure the products she’s responsible for are inclusive and users get equal access to information, functionality, and experience of digital products.

Katarzyna Łukasiewicz - Project Manager. She has been working with agile methods for over 10 years, both as a researcher and a practitioner. She believes in teamwork and a power of user centered mindset. With experience in leading international projects, she knows how to support and encourage timely and high quality deliveries.

## Costs and budget

The work will be divided into 3 milestones. In each milestone, the whole team, as desribed in the previous section, will be working in Sprints, following Scrum approach. Łukasz and Robert are expected to be engaged full time, Pavel half-time, whereas Katarzyna and Joanna will be engaged part-time. The following cost includes all the necessary development, management and design work to reach the defined goals.


**Milestone 1**

Display the gov 2.0 proposals/bounties/child bounties/tips

Time: 3 weeks
Cost: 16 000 USD

The goal of this milestone is to get the gov 2.0 proposals/bounties/child bounties/tips from chain and display them in BrightTreasury.

The proposals/bounties/child bounties/tips from both governance versions will be displayed in one overview, with appropriate label: Gov 2.0 or Gov 1.0. They will be sorted by date. Users will be able to filter out only Gov 2.0 or Gov 1.0 proposals/bounties/child bounties/tips as well.

We plan to complete the following tasks:

1. Checking the gov version support in Kusama net + fetch configuration (when booting the app)

3. List of proposals/bounties/child bounties/tips

- Fetching proposals/bounties/child bounties/tips from gov2.0 & gov1.0
- Handling IDs (may be duplicated)
- Changes in react routing pattern for proposals/bounties/child bounties/tips
- Changes in nest controllers for proposals/bounties/child bounties/tips
- Front+backend communication
- Difference in design for two gov versions (label) for proposals/bounties/child bounties/tips

Out of scope - history of Gov 2.0 proposals.

**Milestone 2**

Display the gov 2.0 proposal/bounties/tips details

 Time: 1 week
Cost: 5 000 USD

The goal of this milestone is to fetch and display the Gov 2.0 proposal/bounties/tips details.

Currently in BrightTreasury the results of a motion for a given proposal are presented in the Votings tab, in the proposal’s detailed overview. We’ll keep this form of presentation for both governance versions. When user visits the detailed overview of a Gov 1.0 proposal, the Votings tab will continue to show the results of a motion. When user visits the detailed overview of a Gov 2.0 proposal, the Votings tab will display the results of the appropriate referendum.

We plan to complete the following tasks:

1. Information on the governance version (label)
2. Voting results - add the new referenda for Gov 2.0 proposals/bounties/tips

**Milestone 3**
Creating and converting Idea/Bounty/Tip in the new Governance 2.0 version


 Time: 2 weeks
Cost: 10 000 USD

The main goal of this milestone is to allow creating and converting Idea/Bounty/Tip in the new Governance 2.0 version.

User will be able to choose the governance version, however by default the choice will be set up as Gov 2.0, with information about it being the preferred option. For each governance version, the submission will be handled appropriately.

We plan to complete the following tasks:

1. Add governance version choice
2. Calculating bond based on gov version
3. Handle different calls for each gov version when submitting proposal
4. Milestones/child bounties Inherit the gov version from their Idea for each network

BrightTreasury - adapting to governance 2.0 

![](https://i.postimg.cc/ZRKjNZRR/Group-383-1.png)

**Summary**


DeStore is eCommerce for DeGens, we are a small team that has built a marketplace for real-world assets with a Digital Twin (DT), to allow Small to Medium Enterprises (SMEs) to get Web 3.0 exposure and DAOs to expand their brand into merchandise.

We are seeking support from the Kusama Community/Treasury to implement drop shipping into our protocol; as well as a loan to bootstrap the DAO drop shipping trial and approval to act as a delegated distributor of Kusama merchandise for the purpose of the trial. 

Learnings from the trial will be captured in a case study that DeStore will produce for SMEs and DAOs to use. The case study for SMEs and DAOs considering to take their brand to next level by adopting Web 3.0 eCommerce, aka Decentralised Commerce (DeCom).

After the DAO drop shipping test is complete, DeStore will provide a long-term solution to the Kusama Treasury to provide the Kusama Community access to official Kusama merchandise via Web 3.0 native tech.



[- Link to the full proposal document](https://docs.google.com/document/d/1jZyooHLBKeD-NuXzjPBovoZt_W3U9_W8CDWVgSEzqak/edit?usp=sharing)

[- Link to Polkassembly discussion](https://kusama.polkassembly.io/post/1810)

[- Link to MVP video](https://drive.google.com/file/d/1j3o9Ip_B-UsxncIqWy9Fq3A9jaEBPVzc/view?usp=sharing)

[- Link to DeStore Twitter ](https://twitter.com/DeStore_Network)


DeStore | Kusama Merchandise Distributor & Dropshipping Trial 

Taking into account the discussion and aiming to achieve consensus, **an external motion** puts forward the vote for treasury proposal by **Fearless**, focused on a browser extension for Chrome and Mozilla, as well as a desktop application for windows, which includes asset, wallet and network management flows, dApp connector logic support and more. Note that this is **an external motion**, leaving the final decision up for the community vote as a referendum. Further information can be found on the [motion post](https://kusama.polkassembly.io/motion/561). The team is here to answer any questions or comments. 

All info on the treasury proposal can be reviewed below.
______________________________________________________________

### #212 Fearless Wallet Desktop/Browser Plugin Proposal

- Link to the original proposal can be found [HERE](https://kusama.polkassembly.io/treasury/212).

- The discussion on the proposal, DMCA action and open source license of the code can be found [HERE](https://kusama.polkassembly.io/motion/551) and [HERE](https://kusama.polkassembly.io/post/1817) (reason why this proposal is submitted on-chain as an external motion). 

This proposal is focused on:

- A browser extension application for Chrome, all chromium based browsers (that support browser extensions) and Mozilla Firefox. In terms of the proposal, our team will design and develop a Browser extension application with a widget style interface that is compatible with and similar to (some extent) the Fearless Wallet mobile app (iOS/Android).

- A desktop application for Windows, macOS and Linux. Using Electron SDK it is possible to build Desktop apps for various operating systems with little effort. These desktop apps can be built from the same code base as the aforementioned Browser extension.

- Wallet, network and asset management flows. We will cover the most important and necessary flows such as: wallet creation and import, handling many wallets, switching between several networks along with the “All networks” state, The main asset flows such as: send, receive, transaction history, teleport (cross-chain transfer), buy assets for fiat by means of Moonpay and RAMP services will also be covered.

- Settings and chain account management flows. Main wallet flows aside, users need to have tools to manage their wallets, chain accounts, localisation, currencies, nodes, etc. The “Settings” set of features will be a solution to that. More detailed information about the corresponding flows is provided below in Section 3. Feature set of the proposal.

- dApp connector logic support. We will develop a service that will allow a direct connection between the Fearless Wallet (iOS/Android) application and Browser extension to sign all dApp transactions.

The amount requested for the first submission is $268,400.00. The amount in KSM is 6,389.41 taking into account KSM EMA (7) rate provided by Subscan service KSM prices (USD) for October, 3rd. The amount will be recalculated according to the 7 day average KSM rate, using the high and low of the week on Coingecko, at the day of on-chain action after the discussion process ends.

**The 1st milestone includes:**

- Browser extension for Chrome, all chromium based browsers and Mozilla Firefox

- Desktop application for Windows, macOS and Linux

- Wallet, network, and asset management flows

- Settings and chain account management flows

- dApp connector/signer logic support




External motion: Approval of Treasury Proposal 212 - Fearless Wallet Desktop/Browser Plugin Proposal

![](https://i.postimg.cc/qMNspcGj/Screenshot-2022-10-04-at-16-17-45.png)
As **Infrastructure Maintenance Bounty** was meant to be open-ended, after the completion of the test period, the team behind the Infrastructure Maintenance Bounty decided to publish a [report and a follow-up proposal](https://docs.google.com/document/d/1tCmnNhXmqNbBQtUEbuIyvwXT99uVFkUZ45GdWRNa2uQ/edit?usp=sharing) requesting a top-up to continue covering the ongoing costs of running reliable public infrastructure for the Kusama ecosystem: including block explorers, governance forums and applications, snapshots and validators service providers, community wallet services and other projects seeking to cover maintenance costs with treasury funds. 

All the details of the proposal, along with the spending analysis, report, enhancements and requested budget, can be found [here](https://docs.google.com/document/d/1tCmnNhXmqNbBQtUEbuIyvwXT99uVFkUZ45GdWRNa2uQ/edit?usp=sharing).

_*Please note that you will not be able to see the beneficiary identity on-chain (this is the address of the bounty, created once the bounty proposal is accepted), but you will be able to check this on [Subscan](https://kusama.subscan.io/account/F3opxRbN5ZbjJNU513biNdUuzGvk6gSBmwggQXh7rttXx6k)_ 

Infrastructure Maintenance Bounty Top-up

Proponent: ELkVhHcvaP9L43RK9SP6Wn3FBfusEN5EJe2gH7aA2ETiufP

Date: 6th October 2022

Requested KSM: 1,295.60 KSM (USD: $59,124.98)

Short description: Ongoing costs for the running of high performance, scalable, and reliable public infrastructure for Kusama and Statemine.

Previous Discussion: <https://kusama.polkassembly.io/post/1868>

Raw Data: <https://docs.google.com/spreadsheets/d/1eftYcA4iedfQiwwekxLvNixhksG3uNMRAU0QGAmI09Y/edit?usp=sharing>

Full Report <https://docs.google.com/document/d/1UW9Cg5FmYoxaT2bDCzYOpMuv-LNmzvvayfe0vgEBKlY/edit?usp=sharing>

* * * * *

## Original Motivation

Over the last 3 months (July, August, September 2022) we've provided a scalable free public API service so that everyone can access public pools of managed Kusama and Statemine nodes. This provides the following three outcomes:
- Grow the ecosystem by reducing the barriers to entry to access a high performance nodes
- Help scale existing projects in the ecosystem by providing infrastructure  services that can be depended on
- Assist with the testing of all networks by providing valuable data back to the community on how validator nodes are running and scaling as the network traffic increases (we've made Github issues based on behaviour we've observed)

## Service Details

During the last quarter, we've focused on three key areas for the development of OnFinality - cost optimization, network expansion, and providing more value from our Ultimate API service.

The bear market has made many of our customers more price sensitive, and as such we've been working with them to optimise our services to provide more for less. We've reduced prices for our larger customers between 30 and 40%, and created products designed to target and onboard new chains with entry level pricing. We've also been working on new rate limiting capabilities to progressively restrict abusers of our public APIs to upgrade to paid API plans.

In the past quarter we have succeeded in our goal of onboarding two new networks, with the addition of Avalanche and Juno to our API service. This was a large amount of upfront work, extending OnFinality to allow chains outside of Polkadot/Substrate, but now that it has been done we should be able to move faster and onboard new chains each week. We hope that this means that we will be able to invite as many new ecosystem participants into Polkadot as possible with this expansion. 

Finally, providing move value from our Ultimate API service has always been a priority, and in this space we've added new API specific paid plans at competitive prices to our competition. We have also delivered the ability for our customers to better understand and learn about their users, with API Insights that tell you where your users are, what they are requesting, what methods are failing (to find bugs in your dApp), and where optimisations can occur.

We continued to execute on our efforts to provide unprecedented service stability and reliability to this ecosystem. All supported networks exceeded our 99.9% target, including 99.94% uptime for Kusama over the last 90 days . At this stage, OnFinality is operationally striving for four 9s of availability, which means less than an hour of downtime each year.

Between 2022-07-01 and 2022-09-30 our Kusama API service has:
- **Reduced cost to the Kusama treasury while serving a similar amount of traffic**
- Served a total of 4.932 billion responses
- Accumulated almost 56 TB of data egress
- The highest daily total was over 102 million responses in a single 24 hour period
- Our rolling 7 day average at the end of this period was over 60 million responses each day.
- Statemine had over 364 million API responses in the period
- All time totals for Kusama is 35,987,582,620 (35 billion) since November, 2020
- At the end of this period the 90 day uptime on Kusama and Statemine was 99.94% and 99.99% respectively

## Enhancements

Additionally, we are proud to have delivered some key service enhancements that benefit the Polkadot ecosystem in the last quarter. This includes:

- [API Insights](https://blog.onfinality.io/onfinality-introduces-api-insights-so-you-can-analyse-and-learn-about-your-applications-faster/) so you can analyse and learn about your API applications faster and find bugs with your dApp
- [Cost optimisations](https://blog.onfinality.io/go-further-with-more-affordable-pricing/) to reduce pricing for our customers by up to 40%
- [New API plans](https://blog.onfinality.io/get-ahead-with-onfinalitys-new-api-endpoints/) for our high usage customers and a way to allocate resource to [move towards a more sustainable funding model](https://kusama.polkassembly.io/post/1815)
- [Support for Alibaba Cloud](https://blog.onfinality.io/onfinality-collaborates-with-alibaba-cloud-to-provide-a-premium-experience-to-web3-builders/) to provide more decentralised cloud hosting options for our customers
- [Updates to our website](https://blog.onfinality.io/onfinality-announces-a-new-ui-to-help-web3-developers-build-smarter/) to include a new Network marketplace so [you can see what networks are supported](https://onfinality.io/marketplace)
- Support for new layer 1s - [Avalanche](https://blog.onfinality.io/onfinality-launches-beta-api-support-for-avalanche/) and [Juno](https://blog.onfinality.io/onfinality-launches-api-support-for-jun-c3-b8-network/) (in Cosmos)
- A variety of improvements to our health metric collection tools and automated recovery scripts to ensure our 99.9% SLA is exceeded.
- Scale improvements to our team, processes, and systems to allow us to provide this same service to any  substrate team

You can always see live data on our API service on our public [status page](https://status.onfinality.io/) and [analytics page](https://analytics.onfinality.io).

Full Report <https://docs.google.com/document/d/1UW9Cg5FmYoxaT2bDCzYOpMuv-LNmzvvayfe0vgEBKlY/edit?usp=sharing>

OnFinality High Performance Public Infrastructure (Q3 2022)

Runtime v9300 Upgrade On Kusama

Good day,

Thanks for all the existing support that we have. We have reached out to few councils members for feedback.

Original Post : [https://kusama.polkassembly.io/treasury/209](https://kusama.polkassembly.io/treasury/209)

The feedback that we got is to separate the RPC and the indexer into 2 proposals as they represents 2 different value chains. We agree and are resubmitting based on the feedback that we have received, removing RPC from the equation.

Currently, this value remained in the proposal:

A Content indexer so that when people searched for educational or articles related to Kusama and Polkadot, we are able to provide a categorization and filtering value to the search result. The target audience is anyone who are interested in the above and wants to join or provide a little touch of their Likes as part of the community feedback to the indexing mechanism. This can be a lurker, a content creator or a technical learner.

The above will help to gather the information done by many content producers that are being posted in so many repeated location and provided a relevancy.

The new proposal, which can be found in below link: [https://docs.google.com/document/d/1HVOfNDEVJ29KInEzDCIPzPBW9QzavI90HjI2b2jxW1E/](https://docs.google.com/document/d/1HVOfNDEVJ29KInEzDCIPzPBW9QzavI90HjI2b2jxW1E/)

We welcome feedback and improvement on the proposal, as at the end of day, the community will be part of us, will also be part of the scalable solution and the enrichment of the data and recommendations. We also want to offer transparency to the proposal. After all, this is supported and funded by the community.

PolkadotSpace - Search Indexer

**Detailed Proposal:**

[https://docs.google.com/document/d/1_ao-Hk-GxIPUDpWijDK4KXUjst0rglZZBzIuMGG7aVQ/edit#](https://docs.google.com/document/d/1_ao-Hk-GxIPUDpWijDK4KXUjst0rglZZBzIuMGG7aVQ/edit#)

**Short Description:**

Support Colorful Notion’s Polkaholic.io open source XCM/Multichain block explorer, indexing of all Polkadot + Kusama + parachain data with a special emphasis on XCM Transfers / Messages, made available in UI/API/CDN/BigQuery form to support Polkadot+Kusama ecosystem’s multichain initiatives.

**Proposal Summary:**

Colorful Notion proposes to:
- Expose and maintain public archive of all the raw data indexed by Polkaholic.io (blocks, extrinsics, events and traces) available in CDN form and then in BigQuery form and indexed data (specifically and especially XCM transfers and XCM messages) in API form
- Continue to index all Polkadot chains to the fullest extent possible to generate and maintain the archive with APIs, which may be relied upon by large scale archival systems.  These APIs maintain Value transfers/XCM transfers according to DEX info on top  “defi” parachains
- Model XCM Transfers and Messages across the entire Polkadot/Kusama ecosystem
- Enhance Polkaholic.io indexing as the Polkadot ecosystem expands: New parachains, new pallets generating XCM extrinsics/messages  with new XC Assets, support for ERC20/PSP22/ERC721/PSP34 assets, XCMv3, and new bridges

Polkaholic.io - Polkadot+Kusama XCM/Multichain Block Explorer (Q2+Q3 2022)

@Councillors, after the team received the feedback, regrouped and answered all questions, the **PolkadotSpace** has submitted an updated proposal that has been passed for Council. Specifically, based on feedback, the team **separated the RPC service proposal and the indexer proposal** and presented the new on-chain submission by removing RPC service from the equation. Please note that with the team's agreement, the motion contains a `batch` call: _approving_ the [updated proposal](https://kusama.polkassembly.io/treasury/217) and _rejecting_ the [previous one](https://kusama.polkassembly.io/treasury/209).

The full proposal, along with the budget and idea behind it, can be found here:
__________________________________________

"Thanks for all the existing support that we have. We have reached out to few councils members for feedback.

**Original Post:** [https://kusama.polkassembly.io/treasury/209](https://kusama.polkassembly.io/treasury/209)

The feedback that we got is to separate the RPC and the indexer into 2 proposals as they represents 2 different value chains. We agree and are resubmitting based on the feedback that we have received, removing RPC from the equation.

Currently, this value remained in the proposal:

A Content indexer so that when people searched for educational or articles related to Kusama and Polkadot, we are able to provide a categorization and filtering value to the search result. The target audience is anyone who are interested in the above and wants to join or provide a little touch of their Likes as part of the community feedback to the indexing mechanism. This can be a lurker, a content creator or a technical learner.

The above will help to gather the information done by many content producers that are being posted in so many repeated location and provided a relevancy.

The new proposal, which can be found in below link: [https://docs.google.com/document/d/1HVOfNDEVJ29KInEzDCIPzPBW9QzavI90HjI2b2jxW1E/](https://docs.google.com/document/d/1HVOfNDEVJ29KInEzDCIPzPBW9QzavI90HjI2b2jxW1E/)

We welcome feedback and improvement on the proposal, as at the end of day, the community will be part of us, will also be part of the scalable solution and the enrichment of the data and recommendations. We also want to offer transparency to the proposal. After all, this is supported and funded by the community.

________________________________________


PolkadotSpace - Search Indexer (rejection of treasury proposal 209 and approval of treasury proposal 217)

The full stack of open source software has been released for developers and parachain teams to run their own custom [Polkascan Explorer](https://github.com/polkascan/explorer). We're happy to see that it's being picked up already, e.g. by the [Dora](https://dorafactory.org/) team.

The next step we would like to take is to improve on its feature set. We've selected a number of improvements, for which this treasury proposal has been submitted. We're available to answer any questions.

Please read [more details in the proposal](https://github.com/polkascan/social-contract/blob/master/kusama/treasury-proposal-214.md).


Treasury Proposal for Polkascan Explorer Improvements

I am Cervera and I have been creating educational tutorial videos and interviews about the Polkadot and Kusama ecosystems since April 19, 2021 on the [Cryptonitas YouTube channel](https://www.youtube.com/channel/UCsP0zGvvzB4RGyDYHkDdmUA). Currently, on my YouTube channel you can find two main playlists, one for [Kusama](https://www.youtube.com/playlist?list=PLbGd7ZIYqZAP3PysUxiwYGW7aHsC60TnN) and one for [Polkadot](https://www.youtube.com/playlist?list=PLbGd7ZIYqZAPR14k1-zSpznR-HSNYHaqa).

All videos made so far have been submitted to Tips and endorsed by the Council. Also, during the last few months I have been working on [this proposal](https://docs.google.com/document/d/1wzXd7k55l-nX7cXIdwDnA1WwMIKIVCXYMLprlqMraeY/edit?usp=sharing) for the production of Kusama's educational video tutorials.

The following proposal seeks funding for the production of 64 educational videos about the Kusama ecosystem from November 2022 to April 2023. This proposal is born as an extension of the proposal mentioned above in order to expand the functionalities that make up the Kusama playlist, inform users of what happens weekly in the network governance and give them support in case they need it.

The objective of this proposal is to create an informed, educated and valuable community that knows how to make real use of the network.

You can see the full proposal [here](https://docs.google.com/document/d/1u15Yub1VQxqvhf3juk8JGFr4u1BrqvH1SUgxrzBQ1bE/edit?usp=sharing).

You can check the original discussion [here](https://kusama.polkassembly.io/post/1828)

Production of Kusama ecosystem educational videos in Spanish

The proposal puts forward the vote for treasury [proposal 212](https://kusama.polkassembly.io/treasury/212) by Fearless, focused on a browser extension for Chrome and Mozilla, as well as a desktop application for windows, which includes asset, wallet and network management flows, dApp connector logic support and more. Note that this is `batch` call: the rejection of treasury [proposal 211](https://kusama.polkassembly.io/treasury/211) is included, as the proposer made a mistake when submitting on-chain. This is replaced by the vote of treasury proposal 212 in the same `batch` call.

- Proposal 212 (correct one): [https://kusama.polkassembly.io/treasury/212](https://kusama.polkassembly.io/treasury/212)

- Proposal 211 (incorrect one): [https://kusama.polkassembly.io/treasury/211](https://kusama.polkassembly.io/treasury/211)

- Discussion post: [https://kusama.polkassembly.io/treasury/212](https://kusama.polkassembly.io/treasury/212)

Kusama Treasury Proposal for Fearless Wallet: Browser extension and Desktop Applications

Statemine Runtime Upgrade to v9290

Good day,

We are writing this proposal with regard to some of the experiences that we are getting as a user and/or a validator within the eco-system. We do understand that a lot of help is being proposed by the community members, but at the same time, we have to do our own research in regard to information/news that we are looking forward to.

What we want to help the community is to address a typical behavior of Web2 and the nature of our internet environment. IE: INFORMATION is "ALL Over The Place" from either Blogs, video site, other blogs and blogs and discussion website and sometime, social media.

There are 2 values in this proposal

A Content indexer so that when people searched for educational or articles related to Kusama and Polkadot, we are able to provide a categorization and filtering value to the search result. The target audience is anyone who are interested in the above and wants to join or provide a little touch of their Likes as part of the community feedback to the indexing mechanism. This can be a lurker, a content creator or a technical learner.

The above will help to gather the information done by many content producers that are being posted in so many repeated location and provided a relevancy.

RPC nodes for community which we simply want to provide more capabilities to the community and infrastructure as the usage of XCM is increasing dramatically now. In addition to that, the focus will be on Asia and North America because majority of the existing RPC are in Europe. Furthermore, we are also delivering additional archive nodes to reinforce the data footprint of the decentralized eco-system.

Our current Full Proposal can be found below. [https://docs.google.com/document/d/19LXxklsulLc87ffkwHPzfgfQwB86efytHl2SoatRXnU](https://docs.google.com/document/d/19LXxklsulLc87ffkwHPzfgfQwB86efytHl2SoatRXnU)

We welcome feedback and improvement on the proposal, as at the end of day, the community will be part of us, will also be part of the scalable solution and the enrichment of the data and recommendations. We also want to offer transparency to the proposal. Afterall, this is supported and funded by the community.

PolkadotSpace - Search Indexer and RPC end-points

**Sub.ID Features [Proposal](https://docs.google.com/document/d/1RElvy5RYhnNInwnGsjibedGLI3EeBoqqazKk6Syv13M/view)**: Collator and validator staking, Staking dashboard, Crowdloan claims, Cross-chain transfers

![](https://ipfs.subsocial.network/ipfs/QmYSQ8Q2esyeoMXXATcusA8QzMb4aBPwtKsx8sWEfDsxSX)

Launched a year ago, the [Sub.ID](https://sub.id/) web dapp was initially designed to provide quick and convenient access to all your Substrate addresses, balances and other assets in one place. It was built with the Dotsama ecosystem in mind and tailored to benefit its most active members. Since then, Sub.ID has been connected to over 30 Substrate chains, gained substantial traction, and got its own dedicated vision and roadmap.

We are seeking to secure funding from Kusama treasury for the following community-oriented features:

BATCH ONE
- **Collator and validator staking**: network selection, stake / unstake buttons and actions, collators / validators list, parachain / FRAME staking pallets support
- **Staking dashboard**: staking analytics, data aggregation, APR calculation, rewards calculation
- **Crowdloan claims**: claim buttons and actions, claim/vesting pallets support (backend/frontend), human friendly time to unlock staked tokens
- **Cross-chain transfers**: native & cross-chain transfers (UX/frontend), tokens pallets support (native transfer), XCM pallet integration, support of EVM tokens & transfers

BATCH TWO
- Alternative balance view
- Accounts grouping
- Transaction history
- P&L analytics

BATCH THREE
- Mobile app

The first allocation will only cover BATCH ONE features for now, the rest are our plans for the future.

Please review the full proposal with detailed description costs at [https://docs.google.com/document/d/1RElvy5RYhnNInwnGsjibedGLI3EeBoqqazKk6Syv13M/view](https://docs.google.com/document/d/1RElvy5RYhnNInwnGsjibedGLI3EeBoqqazKk6Syv13M/view). We would love to get your feedback please.

Community-oriented Sub.ID features - Batch one

Runtime v9291 Upgrade On Kusama

Statemine Runtime Upgrade to v9271

WagMedia Request To Top Up Bounty #12

**Who?**

I'm Sara and I've been dubbing the official Polkadot videos into Spanish for 9 months on the YouTube channel called [Polkadot & Kusama - Doblaje al español](https://www.youtube.com/channel/UCdhalsQc7NrYCvYkietak7A). During the first months I was applying to Tips on Kusama’s Treasury, and for the last 3 months I’ve been working on a [Child Bounty](https://docs.google.com/document/d/1hqm_CM8QRvvTNuxMnz4FbvX5A9C_esEWo51pEtD0mfk/edit?usp=sharing). In this proposal I’ll be working with 2 more experienced translators, and with Cervera, who will be in charge of editing the videos.

**What?**

Dubbing of [Polkadot Decoded 2022 playlist](https://youtube.com/playlist?list=PLOyWqupZ-WGvcE0HKKnORiFqWNv5onxCf) into Spanish. The Polkadot Decoded 2022 playlist has more than 100 videos that are equivalent to 34 hours of viewing in total.

**When?**

From October to January 2023. It’s important that the Spanish-speaking community has the content of the Decoded 2022 event as soon as possible to be aware of the news of the ecosystem.

**Why?**

- Misinformation. One of the most important things is that the community is informed and aware of the technology so that they can participate in it.

- Lack of English proficiency in the Spanish-speaking community. According to the EF English Proficiency Index (EF EPI), 60.6% of the Spanish-speaking population have low/moderate English proficiency. The remaining percentage is not fluent in English.

- Little content about Polkadot in Spanish. Most of the content about Polkadot and its ecosystem is in English.

- Content subtitled, but not dubbed. Dubbing offers users greater convenience because they don’t have to follow the reading with their eyes.

- Blind Spanish-speaking people who aren’t proficient in English don’t have access to information. From experience in my family, Spanish-speaking blind people who aren’t proficient in English and want to learn need audio content in Spanish about the ecosystem.

- Information may be distorted when passing through third parties. This causes the user to be misinformed.

**Amount requested:**
1,158.47 KSM ($51,158.3) (KSM/USD on the EMA7 on Subscan at the time of submission)

**Marketing & Success metrics:**
SEO. Reach an average of 250k views in total with all episodes. These videos will be accessible to any user through the Polkadot & Kusama - Doblaje al español channel, and will be available for any member to share through other channels and/or platforms (such as Polkadot Hub or the Polkadot en Español channel on YouTube).

**More information? See the full proposal [here](https://docs.google.com/document/d/1NCRXMI_woMHK6hhXKmr6jTss-sbSQOotH1QI55PP1Vw/edit?usp=sharing)!**

Original post discussions can be found [here](https://kusama.polkassembly.io/post/1780).

Proposal: Dubbing “Polkadot Decoded 2022” playlist into Spanish

 [PLEASE REJECT] Kusama Runtime Upgrade to v9290

## Overview

[Bounty #3](https://kusama.polkassembly.io/bounty/3) aims to provide a signing solution to bridge the dApps and mobile wallets, which using Beacon Network as a decentralized peer-to-peer network of nodes based on the matrix protocol, with trustless and encrypted message relaying.

The bounty includes the integration with Beacon SDK with Substrate-based Network, and the integration with Wallet in both iOS and Android. Overall the bounty is completed by the Beacon team, Fearless Wallet team, and Nova Wallet by June 2022.

The bounty includes relatively more work which could be split into different stages. In order to cover the financial risk for the development team, we decide to split the distribution of the bounty into 2 parts. The first part is distributed(on [Subscan](https://kusama.subscan.io/account/FC4tZgWUDpg1AK5uoY7Z9bTaUanemyipoG7Tk8W9YXpxvZ6)) in November 2021 and rest of KSM is hold in a multi-sig wallet on KSM: FC4tZgWUDpg1AK5uoY7Z9bTaUanemyipoG7Tk8W9YXpxvZ6. In June 2022, the rest of the bounty is completed, but the remaining KSM in the bounty can't cover the cost because the KSM price drops in 2022.

As the curator of the bounty, hereby I kindly ask the council to approve the request to top up 1543.17 KSM into the bounty according to the calculation.  

![Time Spent Table](https://raw.githubusercontent.com/hanwencheng/Substrate-Mobile-Injector/main/res/TimeSpent.png)

## Reviews

For the detail of the review of bounty 3 please refer to: 
* [Review of Part 1 on 2021 October - Beacon](https://github.com/hanwencheng/Substrate-Mobile-Injector/blob/main/Submission/202110Beacon_Review.md)
* [Review of Part 1 on 2021 October - Fearless Wallet](https://github.com/hanwencheng/Substrate-Mobile-Injector/blob/main/Submission/202110Fearless_Submission_Review.md)
* [Review of Part 2 on 2022 June](https://github.com/hanwencheng/Substrate-Mobile-Injector/blob/main/Submission/202206Review.md)

## Bounty Distribution Recap

The reward of the bounty is paid in two parts due to the size of the work being big which may introduce financial risk to the teams if we only distribute the reward by the completion of the bounty. 

The first part is summarized in: https://github.com/hanwencheng/Substrate-Mobile-Injector/tree/main/Submission and is distributed by the multi-sig account FC4tZgWUDpg1AK5uoY7Z9bTaUanemyipoG7Tk8W9YXpxvZ6 with 394.328 KSM, the rest KSM reserved for part2 is 694.552 KSM.

The discussion is followed on [Polkassembly](https://kusama.polkassembly.io/bounty/3#75f2df36-575c-4a1e-973d-426fc01542b1)
![First Part Comment](https://raw.githubusercontent.com/hanwencheng/Substrate-Mobile-Injector/main/res/firstPart.png)

The multi-sig wallet is currently handled by 4 accounts for transparency, two from me, one from Pascal of the Beacon team, and one from Anton of the Fearless/Nova team.

To be noticed here. Anton was a team member of the Fearless Wallet team and during the development, he switched his role to only the present Nova team due to the reconstruction of the companies. Anton's role in the multi-sig is not changed as he consistently worked for the bounty and provided useful insights for both teams. This is under the agreement of both the Nova and the Fearless Wallet team, and does not introduce any conflict into the reward distribution.

## Refill KSM 

Due to the volatility of KSM(The KSM price is 368 USD when we distribute the first part of the bounty, now 61.351 USD), we need to add more KSM into the bounty in order to cover the cost of the second part of the bounty.

According to the calculation, we still need 1543.17 KSM.

The KSM will first send to the multi-sig account FC4tZgWUDpg1AK5uoY7Z9bTaUanemyipoG7Tk8W9YXpxvZ6, which is also the original beneficiary of bounty #3. and be further distributed to:
* Beacon team (Paper AG): G4bxLcMawBgsCt3Qj1khSyS1MxorfyHbUXrFyjQ6zySbTrs
* Nova Foundation: H3cSNjAW86NfTecufGPhxutea8KrEcZdPa4XgVKfhTMugej
* SORAMITSU(Fearless Wallet): FyLYnuNoMAVkz1VZMMGZFHDPghQQm1916fCon1CqNt2aXbX

### Future Plan

Currently, the adoption of Beacon Protocol in Polkadot Ecosystem is strongly dependent on the decision if dApps want to integrate Beacon SDK. We find a better way to gain adoption is to integrate the Beacon SDK in the Polkadot.js extension as almost every dApp supports Polkadot.js/extension to connect the wallet. It is also beneficial for dApps because they do not need to extra effort to integrate with Beacon.

So there is some extra work to do on Polkadot.js/extension, the plan is detailed in the Github issue [here](https://github.com/polkadot-js/extension/issues/989)

The beacon team will work closely with Polkadot.js/extension team to make this happen, and apply for a new bounty when it is necessary.

### Contact Information
* Curator: Hanwen Cheng hanwen@litentry.com
* Beacon Network: Pascal p.brun@papers.ch 
* Nova Wallet: anton@novawallet.io
* Fearless Wallet: petrov@soramitsu.co.jp


Bounty #3 Top-up Request

The proposal (the first step of an experiment ideated by paulo // turboflakes.io) aims to proof governance can control two anon proxies that will then be used to manage treasury funds to participate in two specific nomination pools. These pools will focus on over-accomplished 1kvP validators. 

Please note this motion is the first step for a larger proposal that can be reviewed [HERE](https://kusama.polkassembly.io/post/1633). The proposal aims to enact the following [preimage](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x1802081803000181fd5707c1e314bdccbe80a311121ce074cebdc0dead2bbcb1cb0c127aca5f8e0001544c657373205472757374204d6f72652054727574681803000181a7c6cac2bac3e3fae246e998f1d05eb36aa59c3345fedb09a3828eee7ec762000130457870656374204368616f73) to be executed via Governance, to test control over the accounts mentioned in the post. 

Please review and vote at your convenience! If this motion is approved by Council, the proposal will pass to referenda queue to be voted by the community. 

- Original proposal discussion: [HERE](https://kusama.polkassembly.io/post/1633)
- Overall idea (with 2 steps explained): [HERE](https://hackmd.io/G1xhVuF3TwCo_AxrZQRALw)
- Preimage submission:  [HERE](https://kusama.subscan.io/extrinsic/14361315-5)

Bootstrap ONE-T Nomination Pools: STEP 1 (testing the anon proxies)

**Polkadot js plus extension**, or for short Plus, is Polkadot js extension, plus new features. It is a user-friendly wallet to interact with the Polkadot/Substrate based blockchains/parachains through a browser. It allows users to access their account(s), which can also be used to interact with decentralized apps.
Plus is based on Polkadot js extension, and gets constantly updated with it. Plus does whatever the original extension does and more.

![PJP](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/intro.png)

**Motivation**

The reason why we have decided to work on this project is because every day users comment on social media complaining about the complexity of the original application: "why the extension does not show the balance?", "It is too complicated for new/average users to work with", "It is too abstract", " why should we go to another web site to work with the extension?", " how could contribute to the crowdloans via extension?", and so on. Hence, we started to work on the Plus extension to address such concerns/requests from the Polkadot community.

**Polkadot js Plus features**

The following features are currently available in Polkadot js Plus extension:


1. View balances (crypto/USD) ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#accounts-page))
2. Transfer funds ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#transfer-funds))
3. View transaction history ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#transactions-history))
4. View an address as a QR code ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#qr-code))
5. **Regular staking** (stake, unstake, rebag, redeem, nominate, view rewards history, etc)  ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#easy-staking))
6. **Nomination Pools** (join/create pool, stake, unstake, redeem, nominate, manage pool, etc) ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#easy-staking))
7. Supporting different endpoints ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#social-recovery))
8. Crowdloans (View Auctions/crowdloans/contributions and contribute to crowdloans) ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#crowdloans))
9. **Governance** (vote referendums, endorse proposals, vote/unvote councils, view motions, view/submit treasury proposals and view/submit tips) ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#governance))
10. **Social account recovery** ([link](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's#social-recovery))


**Problem statement**

Polkadot js Plus team aims to provide additional new features, and the budget is requested for the development of the 1st milestone:

Milestone 1:

- Re-developing of the current features by completely redesigning of the extension‘s UI/UX: Until now, we were mostly focused on bringing new functionalities to the Polkadot js Plus extension, and tried to be consistent with the UI of the Polkadot official extension. Even though we have received positive feedback from the community, we noticed that the community also wants a new design and user experience. Hence, we have decided to completely redesign the extension, to make users feel more comfortable and focus on what's important, by creating a stylized but instantly recognizable UI. In addition, users be able to efficiently and quickly get most of the common functionalities done on Kusama/Polkadot ecosystem blockchains. Furthermore, we rename the extension to “Polkagate”, to be as the gateway to Polkadot ecosystem.

![polkagate](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/553705cdf85d222b3e9126a715cc122a2fa5ade3/polkagate/intro.png)

- Nomination pools (Phase 2): Nomination pools as a new feature of the Substrate is currently implemented on Kusama, and Polkadot js Plus is among the first wallets to provide this feature for the community. The nomination pool is a work in progress, where some new features are on the list to be added to the blockchain, and also there are some currently added features like “kicking all members out when pool is destroying” and no UI are currently supporting those features. We want to add the nomination pools new features which is not currently available in the extension, such as facilities around Blocked and Destroying state where: If the pool state is in Blocked, and you are the state_toggler or root role, then you should be able to unbond and withdraw anyone else, and if the pool state is in Destroying, then anyone should be able to unbond and withdraw anyone, except the depositor.

- Proxy accounts support: Proxies are a great feature because they add in a layer of security to the Polkadot ecosystem. Rather than using funds in one sole account, smaller accounts with predefined roles complete tasks for the main account. But using this great feature is difficult for users.
As quoted by two councilors below, there is a lot of enthusiasm for using proxies, but almost no support from extensions.
**Will (Paradox)** on Element: “I would love it if I could add a 'proxy only' account in Polkadot.JS/extension, it would require the public address of the real account and the private keys for a proxy account. Any transactions would be signed by the proxy on behalf of the real”. 
**Bryan Chen** on twitter: “Proxy account is such an underrated feature that can significantly improve account security but we have virtually zero support on this amazing feature. It will be great if we can use this feature without switching browser extensions.”
We want to add the support of proxy accounts to the extension so that users can easily create and utilize proxy accounts while minimizing the risk of their main/stash account.


Milestone 2:

- Governance 2 (Phase 1): Almost all of the governance features are currently included in the Polkadot js Plus extension, we would like to have Governance 2 features in the extension as well. Community involvement is still low in governance activities like democracy voting. Sometimes proposals are very technical, and sometimes users may not be available in the voting period to vote. Providing vote delegation besides all governance facilities in Polkadot js Plus extension, will increase the tokens participated in different Governance voting activities. 


- Identity management: Identities exist on-chain but cannot be seen on the extension’s account page, we will bring the Identities into the extension. Accounts’ names in the extension may differ from their on-chain identities, and this may be inconvenient to distinguish which identity belongs to which name/Id. The problem will be more for users with multiple accounts. Moreover, in social recovery, when you lose your account, most probably you cannot remember the address! By integrating the Identity management into the extension, users not only can easily set their identities but also request judgements using the extension. In addition, using the on-chain identity instead of the local name of accounts, makes the accounts management more convenient. Identities also help social recovery be more user-friendly for users. 

- Light client integration: We would like to provide the Polkadot light client as an end point in the extension, which will make the extension much more standalone, and help the ecosystem to be more decentralized. If blockchain endpoints stop servicing for whatever reason, since no data can be fetched from them, hence all extensions and wallets would be useless. Integrating the light client inside the extension not only helps to distribute the Polkadot ecosystem more but also lets the extension operate while all existing endpoints stop servicing. However, we need to consider the sync waiting time when using the light client.

**Incorporating community feedback** ([link](https://kusama.polkassembly.io/post/1764)):

Based on the comments and the discussion on the Kusama Direction channel, we have modified the proposal as follows:

 - we have reduced the redesign section budget by approximately 42% through:
      -  reusing parts of the codes
      -  moving 2 of 10 current features/items for re-developement to milestone 2

  - we have replaced the word "redesign" with "re-develop" which makes more sense
  - we have moved "identity management" from milestone 1 to 2
  - we have added "Proxy accounts support" as a more critical feature to milestone 1

Here you can find the [Revised proposal](https://docs.google.com/document/d/11JGzIuiTfNA5KwKisKB6I-NDQeOXnasn). 
The [previous version](https://docs.google.com/document/d/10T9l6lw4mgjz9rF_Ckhpr8fTgoxHFJkL) is also available for comparison and transparency.



Yours sincerely,

Polkadot js Plus team

Polkadot js plus 1st treasury proposal

Latin America is a region with a large number of developers with worldwide potential in both web2 and web3. We propose a hackathon in Latin America to unite this potential and promote the Substrate technology.

The Latin America Hackathon will be held online and executed during eight weeks, from 26 September to 19 November 2022 (6 days Pre hackathon, 6 weeks hackathon and 10 days for judging period).

[Link discussion](https://kusama.polkassembly.io/post/1790)  

[Link full proposal](https://docs.google.com/document/d/1esL7hKvim9k1S5_PArJaBp80uFlfsE41zD_qUAue1BU/edit#heading=h.o0bnr72yk8mj)

POLKADOT HACKATHON LATAM

Now that [Bounty #14](https://kusama.polkassembly.io/bounty/14) is funded, the bounty is ready to get its curation team to work: the proposers of the bounty [published a curator application](https://kusama.polkassembly.io/bounty/14#2172c0db-d57c-4e7b-8f92-f8456c5a36b3) aiming to become evaluators of the work of community moderators in the official Polkadot and Kusama channels for their efforts and time spent on Discord, Reddit, and Element. You can find their application [here](https://kusama.polkassembly.io/bounty/14#2172c0db-d57c-4e7b-8f92-f8456c5a36b3): make sure to review and vote at your convenience!

- Original Bounty Proposal (approved): [https://kusama.polkassembly.io/bounty/14](https://kusama.polkassembly.io/bounty/14)

- Curator Proposal: [https://kusama.polkassembly.io/bounty/14#2172c0db-d57c-4e7b-8f92-f8456c5a36b3](https://kusama.polkassembly.io/bounty/14#2172c0db-d57c-4e7b-8f92-f8456c5a36b3)

The Curator is a 2-out-of-3 multisig that comprises two representatives from the community and one representative from Web3 Foundation. The signatory from Web3 Foundation will not receive any rewards. This multisig will in turn control an anonymous proxy which we propose to be the Curator of this bounty. 

Review process, multisig members and more information can be found on the links above.


Election Of The Curator For bounty #14:  Moderation Team Bounty

Proposal to fund several events during Berlin Blockchain Week Sep. 12th - 18th.

This proposal is a community led proposal, led by several parachains that have shown high interest in being part of the organizing team of this proposal. KILT Protocol, Phala Network, Subsquid, Crust Network, Bifrost, Basilisk and others came together to lay out a week full of Polkadot ecosystem events and educational content.

Instead of organizing a full one- or two-day conference as it has been done for example during EthCC in Paris, the organizer team decided to approach it in a different way and make use of the full seven days of Berlin Blockchain Week.

The goal is to organize every day a Polkadot specific event based on a different ecosystem topic (Cloud services, UI/UX in DeFi, NFT & metaverse infra, Polkadot updates). Every event is organized in a different style (from boat party to panel discussion and NFT art gallery event) to show the diversity of our ecosystem and use every day of the blockchain week to promote the Polkadot brand.
Events will be live streamed and published on Polkadots official crowdcast. All events are communicated with the official Berlin Blockchain Week events organization TG channel and will be also published on the official events calendar.

**Note regarding beneficiary address:**

Due to the fact that the individuals representing different parachains submitting this proposal are unable to off-ramp the KSM to pay the cost of the event. The Parity Finance will assist by helping off-ramp the KSM and pay for cost of the events. None of the funds will go to Parity directly.

Please see the full proposal here: https://docs.google.com/document/d/1lNnZesUGUTBpr4k9fHLbr61J8qSWppc1/edit

blockchainweek.berlin (https://blockchainweek.berlin/)

Parachain Event series - Blockchain Week Berlin

This is a follow-up proposal to motion [#495](https://kusama.polkassembly.io/motion/495), which limited the number of nomination pools to 64 in Kusama (and 16 members per pool) to prevent the spread of a bug regarding the reward payout. [Runtime 9271](https://kusama.subsquare.io/democracy/referendum/225) (enacted in block #14,248,044) contains a fix for this bug, **and the staking team has observed no further issues with nomination pools.**

Therefore, this proposal aims **to lift the limits imposed on the nomination pools by motion 495**: the new limits are 256 total pools and 1024 members per pool. Recall that even these limits are just a safeguard and in practice no limit on the number of pools and members per pool exist. 

Please make sure to review the proposal hash (the construction can be found [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x290a00000100010000000100040000)) and vote at your convenience! - preimage has already been submitted. 

Update to Nomination Pools on Kusama

To be able to recover inside an epoch on Kusama and prevent an offline event or potential slashing, we built a snapshot solution that allows bootstrapping a Kusama/Polkadot validator in less than five minutes to continue producing blocks.

The goal of our proposal is to be able to sustainably offer Parasnaps for free to everyone. With the proposal, we can cover the costs incurred over the last six months.

The full detailed proposal is available **[here](https://hackmd.io/@tugytur/HkcUEt5C9)**

Proposal: parasnaps.io six months maintenance

Dear community,

We're proud to present our very first proposal from the Sublab team which primary focus is on developing tools for developers in Substrate ecosystem.

Please feel free to read the full proposal document at this link: [https://docs.google.com/document/d/1cvQw2bf2uH3qEJR2594Hj5FtmsxbcaKoodZYyKwJkx4/edit?usp=sharing](https://docs.google.com/document/d/1cvQw2bf2uH3qEJR2594Hj5FtmsxbcaKoodZYyKwJkx4/edit?usp=sharing)

![](https://sublab.dev/logo.png)

**Context of proposal**

[sublab.dev](sublab.dev) is the company designated to develop fully native open-source libraries for mobile platforms in Polkadot and Kusama ecosystems, covering everything with reliable unit-tests and providing rich documentation to the developers community. 

We’re a team of 3 engineers at this moment, consisting of 1 Senior iOS Engineer; 1 Support Engineer; and former [Fearless Wallet](http://fearlesswallet.io) Technical Lead, proficient in both iOS and Android development since 2010, who led Mobile Departments in several companies, including his own, and knows everything about mobile apps architecture. Our goal is to reach the current state of ecosystem needs in our libraries as soon as possible, starting with a few people to build a strong and reliable foundation to be used further to develop as many APIs and different chain clients as possible. Last, but not least, we want to provide technical support in our Telegram chat for developers having questions about integration to their mobile apps.

Right now, we would love to start with the development of SCALE codec as this is the one of the basic dependencies to do anything in the ecosystem. As stated in [Substrate Docs](https://docs.substrate.io/v3/advanced/scale-codec/#implementations) there are no existing ready-to-use libraries for this purpose in Swift or Kotlin. Even though such implementations already exist in a couple of live mobile wallets, it’s not covered with documentation, has outdated unit-tests, and strongly tied to existing libraries codebase which are very specific for wallets needs. And then finalize the current milestone with basic Substrate client implementation.

**What we're trying to accomplish within this milestone**

Right now there are only a few mobile apps in the ecosystem, and almost no ready-to-use tools for new players in the market. Existing apps share their source code, but it would take huge efforts and a big amount of time for even very strong developers to dive into the ecosystem development, because if they’re not familiar with the ecosystem philosophy and technical aspects, they will definitely need to learn from the beginning. So, basically speaking, only the strongest developers could easily (or not so) step into the development inside the Polkadot and Kusama ecosystems. 

Thus, as we see it, to make it possible for the ecosystem to grow more and attract more mobile developers to it, there is a need for strong, reliable, open-source, well documented libraries to kickstart more innovative projects. **With the tool set of easy-to-use transparent libraries, we believe that the entry threshold into the ecosystem will fall down and will let even more developers start working with it.**

Existing SCALE codec implementations for mobile platforms do not provide any documentation, have outdated unit-tests, have a redundant interlayer of JSON key-based serialization which is a specific requirement for their app needs, though not follow pure SCALE responsibility and designation. 

At the very beginning, we want to solve this problem by making fully native open-source libraries which give both options to end developers: 

- Work with SCALE codec as it was designed
- Work with SCALE codec by slight transformation with interlayer between

On top of it, we’re planning to build **Substrate client libraries**, which by using the SCALE toolset will cover basic messaging with any potential Substrate-based network. At this stage, we would like to exclude the signature routine from this library, because this requires more time to make architectural solutions regarding support of different signature methods and how to properly inject them depending on various chains already out there. However an existing set of signatures in the ecosystem by the date of publication will be supported within this milestone.

**Our mission**

We want the Substrate ecosystem developers to just do brand new features to make the ecosystem richer and be recognizable by even more people around the globe, while we can hold their backs by doing a great infrastructural work. We want to see more mobile apps in the ecosystem either from existing parachains to launch their own apps or absolutely new mobile wallets with more innovative functions. Same we want to help existing applications by solving their core issues within our works and help them adopt our products. Also we aim to partner with as much as possible existing networks and/or companies who already deliver their services to ecosystem, so that even their products might be easy accessible via reliable SDKs.

**Proposal financing and deliverables**

We're requesting $81,900 for the current milestone which includes both SCALE codec implementation and Substrate client library implementation. Both parts are planned to be released separately and sequentially along with publications to public package managers' repositories, as well as on our GitHub for a review. Also we're planning announcements on our Telegram channel and future Medium blog with a brief description of deliverables. And in the end when we finish documentation part we're going to publish on-chain report with appropriate links to the open source code, package managers' repositories, our articles on Medium, and links to documentation website.

**Epilogue**

We look forward to hearing from you any constructive feedback and/or questions regarding our planned works. Feel free to refer to our [proposal document](https://docs.google.com/document/d/1cvQw2bf2uH3qEJR2594Hj5FtmsxbcaKoodZYyKwJkx4/edit?usp=sharing)

Sincerely,
Sublab team

Sublab proposal #KSM-1: Foundation. Mobile SDKs for SCALE codec, Substrate client, fully covered with tests and provided with documentation

**KusamaHub Proposal:** 

[https://docs.google.com/document/d/1kZHjtVqiiHyF6atAZLTi1tvv_mTK-rgRja4NxWi73_o/edit?usp=sharing](https://docs.google.com/document/d/1kZHjtVqiiHyF6atAZLTi1tvv_mTK-rgRja4NxWi73_o/edit?usp=sharing)


**KusamaHub Costs Detalization:** 

[https://docs.google.com/document/d/1H4mE9G5UF-VJr4r1Wi8GkfYXSFmXL146G6QunG0pzp8/edit?usp=sharing](https://docs.google.com/document/d/1H4mE9G5UF-VJr4r1Wi8GkfYXSFmXL146G6QunG0pzp8/edit?usp=sharing)

**GitHub:**

[https://github.com/KusamaHub/KusamaHub
](https://github.com/KusamaHub/KusamaHub)

**DEMO:**

[https://kusamahub-demo.github.io/web-demo/index.html](https://kusamahub-demo.github.io/web-demo/index.html)

**List Functions:**

[https://docs.google.com/document/d/1zxbh9tLCDBjMQ2r2zMATvbqJQ7ZRbVdxkwCYYmgQAnY/edit?usp=sharing](https://docs.google.com/document/d/1zxbh9tLCDBjMQ2r2zMATvbqJQ7ZRbVdxkwCYYmgQAnY/edit?usp=sharing)

**Q&A:** [https://docs.google.com/document/d/1PPCSosV8KXF8uxL1iEKcBYq5ibphl8Uk7Xj_8dmP4Es/edit](https://docs.google.com/document/d/1PPCSosV8KXF8uxL1iEKcBYq5ibphl8Uk7Xj_8dmP4Es/edit)

**KusamaHub** is an Analytic Tool. We collect all NFTs projects information from the Blockchain and we store them in our Database. 

We also get data from Twitter, Discord, Telegram, project’s websites and, even more important, we provide the users with the opportunity to communicate and discuss projects with more transparency from both Collector's and Creator's sides. 

Based on the information collected and the user’s opinion, we make detailed analytics, which helps estimate the NFT Projects or a Creator, and get all information about sales, prices changes, holders. 

**KusamaHub** provides different tools and widgets, such as Calendar, News, and more.
Our goal is to give the community a better analytics tool full of features with information about Kusama NFT Projects and Creators.

We get information about NFTs directly from the Blockchain to give users detailed statistics about Sales, Holders and more, at the same time Creators are required to fulfill different information about their Projects.

**Users first - is our motto, Transparency - is our language:** Users at any time can vote or leave  a comment about their feeling on a Project Page or directly under the Creator Page.
Easy-to-use and easy-to-manage, in a single platform a user will be able to see all the information from Twitter Account, their Telegram Channel and their Discord Server, also it is possible for Users to see all the Mentions that a project receives on Twitter.
For Creators and Users will be available the Calendar Tool allowing Projects to program new lists and auctions on a certain date, and every user will be able to see this.
Creators have the opportunity to write down in the Project Page full information about their projects.



We are pleased in receiving any questions and suggestion about our project and idea about it's realization.


Original post of the discussion: [https://kusama.polkassembly.io/post/1645](https://kusama.polkassembly.io/post/1645)

KusamaHub

Including the contextual information of [the bounty proposal](https://kusama.polkassembly.io/bounty/14) below:
__________________________________________________________

"Dear community,

I am proposing the creation of a bounty for funding an incentive for the moderation team. We have opened discussions on [our proposal](https://kusama.polkassembly.io/post/1644) for two months and have received no community objection.

Summary Reddit, Discord, and Element are three Social Media platforms that Polkadot/Kusama ecosystem use to communicate and educate older and newer users alike as well as builders, content creators, and even those who fund projects. Social media can be quite a hectic place to have discussion, with everyone being able to put their opinion out there.

These avenues also open up new ways to scam users or commit fraud. This is where the moderation team comes in. The moderation team acts as a first line of defense against scams for all the platforms and ensure conversations stay on topic as well as stay respectful and follow the rules. Moderators not only act as a defense against hostile actors, but they act as educators as well.

For most users on the server, the moderators were the first people in the ecosystem to give guidance on finding out more information regarding Polkadot/Kusama. This bounty aims to reward those moderators and perhaps future moderators for ensuring the safety of the server as well as educating users. It is not meant to act as income, but as a token of appreciation for the hard work that goes into moderating.

For more information, please refer to the proposal, which can be found [HERE](https://docs.google.com/document/d/17bjVgOOprGsz8DGn6D6_thEQyNZRaMSYZbDpsTOud2w/edit#heading=h.kl7lv0cg56u1)."

Bounty #14: Moderation Bounty for Community Comms Channels

Statemine Upgrade to Runtime v9270

Overview
--------

**The Sovereign Nature Initiative**

[Sovereign Nature Initiative](https://sovereignnature.com/) (SNI) is a non-profit foundation that has brought together multiple partners and engineers from the Kusama ecosystem including [Kodadot](https://nft.kodadot.xyz/), [Unique Network](https://unique.network), [Kilt Protocol](https://kilt.io), [Momentum](https://odyssey.org/explore-momentum), and [Ocean Protocol](https://oceanprotocol.com/), to support the building of Web3 capacities for wildlife conservancies and other NGOs working on restoring and protecting biodiverse ecosystems.

SNI's KWT Hackathon is an online event for crowdsourcing solutions for wild-life identification with computer-vision techniques and onboarding these identities on web3 data and ssi protocols, as well as presenting these identities in different ways in the metaverse. This effort has a major impact on conservation, which currently disposes of manual techniques, taking up to 6 months to process, resulting in siloed physical profiles.

**Venue:** Odyssey Momentum online Hackathon space: sni.odyssey.org

**Hackathon Dates:** October the  7th until November the 6th

**Winners Announcement:** Tuesday the 7th of November

Candidates should apply before the 12th of September 2022 by completing [this form.](https://docs.google.com/forms/d/e/1FAIpQLSd22MYldgFgyxj0HX5CaIq7CIAgzs8y_6gDhnM4gaupipMrjw/viewform?usp=sf_link) 

We will let applicants know if they are invited or not by the 16th of September 2022. 

**Beneficiary address:**
G2bC9gtyHBkxmg65nZiZ7pbrV7PMLNXUTwr6dqMUk8KDxXG

**Submitter address:**
G2bC9gtyHBkxmg65nZiZ7pbrV7PMLNXUTwr6dqMUk8KDxXG

Community Spend & Deliverables
------------------------------

The pledges we are seeking from the Council will provide prizes to enhance the reach and impact of these project -- 320 KSM in prizes for the winners of the contests, which will encourage them to continue building their DApps to full fruition after the Hackathon for the benefit of KWT and other conservancies around the world dealing with similar challenges (see description below).

### Amount to spend from the community pool

**Total Ask: 320 KSM**

**Distribution:**

-   80 KSM to the first 2 Winners (1 winner per challenge)

-   48 KSM to the first 2 Runners-up (1 runners-up per challenge)

-   60 KSM to be equally divided amongst the remaining teams

The Jury will be composed of representatives of KWT, SNI, and 2 experts from the field of technology and conservation. The Jury will select 4 winners to which it will distribute such an amount. In its decision, the Jury will be looking for novelty, ease of implementation with existing technologies, the degree of impact and efficiency the solution brings to the conservancies' operations, and other relevant factors such as cost of implementation etc.

Introduction to the KWT Hackathon, the Challenges & Ecosystem Growth opportunities

The Web3 for nature restoration and conservation space is growing exponentially, with Hackathons, grants, and investments flooding into this emerging ecosystem. The aim of this Web3 movement is to bring forward the development of tools and token economic models that could support NGOs and other wildlife conservation organizations to find alternative solutions to finance and manage their vital work of protecting and restoring wildlife ecosystems.

This space, loosely defined often as ReFi, Regen Community, or Web3 for Nature is currently led by Ethereum, Polygon, and by the work of Regen.Network which is part of the Cosmos ecosystem.

Sovereign Nature Initiative is recognized as a leading node in such an ecosystem and together with strategic partners such as Kilt Protocol, KodaDOT, Bitgreen, Momentum, and Unique.Network is trying to advocate for the use of the Kusama ecosystem as the "go-to" chain for environmental projects due to its recognized lowest carbon footprint in the market, and its federated framework for governance and decision-making, which are vital features for conservancies and other land stewards. 

To foster innovation in the ecosystem that is both beneficial for the network and builds capacity for nature stewards working in the field, SNI hosts online Hackathons and [Incubators](https://sovereignnature.com/programs/germinators-program) in partnership with conservancies globally.

Building on the success of our latest [competition](https://sovereignnature.com/winter-2022-hackathon-challenge) supported by the [Treasury](https://kusama.polkassembly.io/motion/425), and our recent [May 2022 Experimental Zone](https://sovereignnature.com/tpost/52pojp8lo1-reflections-on-experimental-zone-1) in Amsterdam, in October-November this year we will again be inviting the most talented Web3 teams from around the world to build tech in service to the health and balance of life on our planet.

In this iteration, we are partnering with the [Kenya Wildlife Trust](https://www.kenyawildlifetrust.org/) (KWT), an NGO committed to the protection and conservation of predators and their ecology, situated in the Maasai Mara National park in southwestern Kenya.

KWT, aware of the potential of emerging decentralized technologies, has identified two specific problems they invite teams to tackle:

-   The identification of lions through computer vision models

-   Predators and farmers' conflict management through spatio-temporal prediction modeling and other conflict mitigation approaches

Improving the lions' Identification process and ID management

A significant portion of KWT's resources is spent on the identification of predators in the Maasai Mara ecosystem. These identifications allow staff to monitor the population and  create model-density estimates and distribution trends, data which are essential for conservation. Due to their physical characteristics, individual lions are more challenging to identify than other predators and the images are painstakingly screened and processed by three employees.

This challenge is a fantastic opportunity to develop the capabilities of protocols and teams working on verifiable credentials such as our partners at Kilt Protocol.

### Predators and farmers' conflict mitigation

The survival of predators in a mixed-use landscape like the Maasai Mara depends upon the goodwill of people to coexist with other non-human and undomesticated life. In the Maasai Mara ecosystem, farmers and wildlife live in close proximity, and predators often prey on cattle. Successful measures have been taken to build better protection and deterrent mechanisms. Still, KWT knows that more can be done to create truly resilient means to support cohabitation, which considers both the socio-economical context and the everyday life of farmers' communities. We, therefore, invite teams to harness their creativity, skills, and expertise toward building tools that can serve as facilitators of a new symbiotic relationship between human communities and predators.

Ideas might include, but should not be limited to, providing the technological and economic tools for communities to safely cohabit with predators, and creating the conditions for farmers to understand the importance of predators, and participate in the value predators generate by regulating the complex dynamics of the savanna ecosystem.

This is a wonderful opportunity for protocols and teams working on data markets and IoT to validate and expand the use cases of their technology. For example, machine learning can be done using Ocean Protocol Compute-To-Data service which will allow us to hide lion tracking data from the public while opening it to data processing and prediction modeling.

### Target Group

Ideal participants are labs, startups, collectives, or companies with a heart for conservation, an ambition to build life-sustaining systems, and who are well versed in some or all of the following technology stack:

-   Web3 - wildlife and biodiversity data oracles.

-   Token Engineering - crypto native models for conservancies funds distribution.

-   Spatio-temporal prediction modeling - wildlife mobility predictions and human-wildlife conflict mitigation.

-   Citizen Science - applications for wildlife tracking and identification.

-   Computer Vision models for wild animals recognition, identification, and tracking.

Previous experience working on similar conservation projects is desired but not required.

**Maximum Team Size: 8 members**

Our intention is to have at least half of the participants based in the African continent. We foresee this being an excellent opportunity for Kusama to grow its ecosystem in the East-African region, which is currently dominated by other protocols and their respective supporting communities.

**Open Source**

Nature doesn't care about ownership. In the spirit of open collaboration, all software developed during the Hackathon should be licensed under Open Source license.

SNI Hackathon with Kenya Wildlife Trust: Treasury Proposal

> **Proponent:**
Blockchain Rio 2022

> **KSM Account:**
EiUauQdEZkF4WxiuUw8hP5VtwFxGkRmrhL2hskdgE6RnNeK

**Contact:** 
Eduardo Cardoso (Executive Producer)
ecardoso@polkadot.com.br //// Discord: _ecardo5o#3065

Date: 13 August 2022
 
Currently planning to have the event beginning on September 01, 2022. Ideally, to receive the fund as soon as possible. 

> The deadline for knowing whether or not the Council approves this initiative is August 19, after which there will be no conditions for its execution in time. 

Once this proposal is approved, we will start our initial expenses with liquidity provided by Francisco Carvalho (organizer of Blockchain Rio) and as soon as the resources are available we will have to carry out this reimbursement.

**Requested KSM:**
$244,043.80 USD (3,998.75 KSMs)

**KSM Value:**
$61,03 USD (calculated by the 7 day average rate on 13/08/2022)

![](https://i.ibb.co/vmbNRCN/Captura-de-Tela-2022-07-14-a-s-04-54-34.png) 

> The citation of People, Institutions and Projects in this proposal is for DOCUMENTARY nature only and DOES NOT MEAN any kind of ADHESION, PREVIOUS SUPPORT or that the ideas presented here ARE NOT SUBJECT TO QUESTIONS. This is an inclusive Proposal. Our production will be open to anyone who wants to expose their projects and ideas, whether they are Ambassadors or Representatives of Parachains, Dapps and Teams. Just get in touch by email: contato@polkadot.com.br. 

This proposal is the result of two months of intense discussions involving its developers and also a lot of feedback that came from members of Parity, WEB3 Foundation, the Council, the Ambassador Program, Parachains and DAPPs, journalists, local audiences, as well many specialist professionals in working within the ecosystem.

> The first challenge after so much feedback is reconciling so many different views and expectations. It is simply not possible to please everyone. And between so many extremes we decided to follow a path that remains viable and that we believe will be the one that will give the best results.

[Blockchain Rio](https://www.blockchainrio.com.br/) ([https://www.blockchainrio.com.br/](https://www.blockchainrio.com.br/)) is a very rare opportunity in Brazil. To establish ties with corporate, institutional and government decision-makers. And also to make contact with students (college, university and even postgraduates), developers and creative professionals. All of it is in a country of continental size marked by a festive culture and which is open to understanding and applying our knowledge.

So far, there is no other event in Brazil or even LATAM that has managed to gather so many guests (more than 250) that represents multiple sectors interested in this market, promoting a cross dialogue between them. And our planning captures this concept very well, making DOTSAMA appropriate this narrative about the future of WEB3.

**LATAM Let's Grow with DOTSAMA!**

![](https://i.ibb.co/B3x2jKh/Captura-de-Tela-2022-08-13-a-s-00-51-41.png)
**Full Proposal (FINAL VERSION)**
-[https://docs.google.com/document/d/1BUZLS1EBICh9yzUDC5ayw31lsYvOqUW_t2Vcn8I_YaE/edit?usp=sharing](https://docs.google.com/document/d/1BUZLS1EBICh9yzUDC5ayw31lsYvOqUW_t2Vcn8I_YaE/edit?usp=sharing)

**Pré-Proposal for Discussion**
- [https://kusama.polkassembly.io/post/1742](https://kusama.polkassembly.io/post/1742)

![](https://i.ibb.co/0Cxt0pz/Captura-de-Tela-2022-08-13-a-s-00-51-21.png)
![](https://i.ibb.co/T1CGQw9/Captura-de-Tela-2022-08-13-a-s-00-51-04.png)
![](https://i.ibb.co/VLLLh7f/Captura-de-Tela-2022-08-13-a-s-00-50-43.png)
![](https://i.ibb.co/YjDhxjn/Captura-de-Tela-2022-08-13-a-s-00-50-23.png)
![](https://i.ibb.co/ws5bk7H/Captura-de-Tela-2022-08-13-a-s-00-49-57.png)
![](https://i.ibb.co/WHdFwsj/Captura-de-Tela-2022-08-13-a-s-00-49-39.png)



**The Proponent of this Project is a Multisign formed by:**

**Francisco Carvalho** - Founder and Ceo of Vision Realty (Real State) and Blockchain Rio. Specialist in Blockchain at MIT, he is also an Advisory Board Member in Venture Capital: Crypto Valey Associate.
- [https://www.linkedin.com/in/francisco-carvalho-706b2bb5/](https://www.linkedin.com/in/francisco-carvalho-706b2bb5/)

**Eduardo Cardoso (ECARDO5O)** - Creative and Project Director since 1998, elected member of the GLMR APES DAO's Council (the top 1 NFT collection on Moonbeam Network). He has been working as a Communication Consultant and Product Planner in the Traditional Financial Market for over 20 years, accumulating awards in Brazil and abroad. Regularly contributed to the development of the ecosystem as a Speaker, Editor (polkadot.com.br) and also as one of the Creative Directors at the Kappa Sigma Mu Society Brand Project. On Youtube, he collaborates on the Polkadot Brasil, Polkadot Spanish and PolkaCortes channels and has had 2 award-winning pieces in animation (for Astar and Parallel) in the Polkadot Year-End Contest (2021 edition).
- [https://www.linkedin.com/in/eduardo-cardoso-perfil/](https://www.linkedin.com/in/eduardo-cardoso-perfil/)

**Tiago Lucer** - Systems architect, Educator, Project analyst and one of the founders of the DOTSAMA Community in Brazil. He will give the final approval on the financial outflows of this wallet and will act as an observer of the Community regarding the applicability of the funds to fulfill the objectives of this Proposal.

> This Proposal was only possible because of the constant, fast and accurate support of the Organizers of Blockchain Rio, Hacking Rio, Rio Crypto Hub, Brasil NFT and Código Brazuca (Educational Program responsible for the first two permanent nodes for Kusama and Polkadot in Rio). All these collectives form the core of the main initiatives involving WEB3 in the city of Rio de Janeiro.

![](https://i.ibb.co/WPkXdBt/Captura-de-Tela-2022-08-13-a-s-00-49-00.png)

BLOCKCHAIN RIO /// PROPOSAL /// DOTSAMA ACTIVATION

This is a proposal to extend the lease of Statemine, a common good chain dedicated to balances and fungible and non-fungible assets, by about two more years (16 lease periods).

Besides continuing its role as an entry point into the Kusama network for assets, especially those backed by off-chain reserves, in the next year Statemine will also start taking on more "system level" functionality, namely regarding KSM balances. With the rollout of XCMv3 and additional features like asset locking over XCM, future chains dedicated to subsystems like staking and governance will rely on Statemine to lock KSM for use in other parachains.

While this two-year lease is longer than leases available on auction, it is meant to represent Statemine becoming an extension to the Kusama protocol itself.

Releases are published in the [Cumulus repo](https://github.com/paritytech/cumulus/releases).

If people agree that this proposal as configured is worth a vote, then we will put it to public referendum.

Hash: `0x4272f0f5d52548e488339bf52861af98904a7f7509b5a067c1ba713b4af813e8`

![](https://i.ibb.co/gWw1yHT/Screenshot-2022-08-10-at-08-41-13.png)

Statemine Common Good Lease Renewal

Encointer Runtime Upgrade v8

[**motion 522**](https://kusama.polkassembly.io/motion/522) is now up for vote: the proposal’s main goal is to fund the development and maintenance of [ONE-T](https://apps.turboflakes.io/#/one-t/kusama/parachains/overview): already an alpha prototype application where the community can visualise reports from simple network status dashboards to a list of validators with several para-validator key data points and real-time charts. Budget, milestones and maintenance items can be found on [the full proposal link](https://hackmd.io/@turboflakes/BJ2i1pz3q). 

Please note this is a batch call motion including: a `rejectProposal` call for [treasury proposal 194](https://kusama.polkassembly.io/treasury/194) due to a mistake by the submitter and an `approveProposal` call for [treasury proposal 195](https://kusama.polkassembly.io/treasury/195): the correct submission for the development of ONE-T. @paulo is here to answer any questions and comments. 

Please review and vote at your convenience!

ONE-T Web Insights Treasury Proposal

Hello Community,

Kusama, and generally speaking Substrate built block-chains have tremendous potential to deliver decentralized computing, however depending on how they are deployed and operated by the community the resulting system can be more or less centralized/decentralized.

Polkawatch is an analytic tool designed to measure effective decentralization of Polkadot/Substrate’s Validation process.

This proposal aims to roll-out Polkawatch for Kusama.

Our [detailed proposal can be found here](https://docs.google.com/document/d/1f7ZWZ0W6Njp5r3qnEVnh4vulBGDBHrQ7Fgzmpqazrl4/edit?usp=sharing).

Proposal for roll-out of Kusama Decentralization Analytics

> This is a follow up proposal to what we submitted before:

> [#94 Cloudflare Enterprise Plan for Subscan from January 2022 to April 2022](https://polkadot.polkassembly.io/treasury/94)

> [#95 The Infrastructure Costs of Subscan for Polkadot Network from Sep 2021 to Dec 2021](https://polkadot.polkassembly.io/treasury/95)

This proposal is used to pay the infrastructure costs of the Polkadot network and its testnets. The payment involved in this proposal does not include any software development, human resources, etc. 

Previously, every infrastructure cost of Subscan was applied by submitting treasury proposals separately. The application time was asynchronous and the process was complicated, which is easy to cause some confusion to users, and it is inconvenient to clearly obtain the monthly cost. Therefore , this application will count all unpaid infrastructure costs of the polkadot network before June 30, 2022, including:

- GCP: January 1st - June 30th
- Datadog: January 1st - June 30th
- Cloudflare: April 15th - June 30th

In the future, the billing time of all bills will be completely unified, which is more convenient for community management and supervision.

This time, we plan to apply for **13,091 USD in Kusama**, the amount of KSM will be converted based on the **EMA7 price** on the day of the official submission.  

- 2022-07-27 10:59:00 (+UTC), Block #13743315
- KSM EMA7 Price ( USD ): 60.151;
- Number of KSM: 217.632
>https://kusama.subscan.io/tools/price_converter?value=13091&type=time&from=USD&to=KSM&time=1658919600

**Billing details can be read [here](https://docs.google.com/document/d/1wXSELzfmNH1CP9JbI5Nq1wu8H83vnxJJ22TEjkF2Wgg/edit?usp=sharing).**

Subscan | Infrastructure Costs of Subscan for Kusama Network

Parallel-Heiko lease swap before the LP22 ends

As a new slashing event happened in era 3995 and it remains unapplied until now, the operator is requesting **the cancellation due to nodes suffering several errors** described in the [proposal post](https://kusama.polkassembly.io/post/1730). It would be good to hear the Council’s opinion and the community on this matter: I have opened the motion for Councillors to decide based on the Staking team’s opinion in [the original post](https://kusama.polkassembly.io/post/1730). More information, including Github issues and the reasoning behind the request, can be reviewed on the link above.

- Original discussion link: [HERE](https://kusama.polkassembly.io/post/1730).

Please review and vote at your convenience!

Cancellation of slash or in era 3995 - At operator's request

Original Discusion **[here](https://kusama.subsquare.io/post/3)**.

During the **Q1** of 2022 **Chrawnna Corp.** delivered 5 weekday Dotsama-focused news videos every week and established a prototype of **WagMedia** — a Discord-based reward delivery system focused on connecting those who want to Share, Create, and Distribute the Story of Dotsama with sources of funding.

In **Q2**, The Kusamarian brand was created, gaining over 1000 followers on [Twitter](https://twitter.com/TheKusamarian), aiming to deliver even more frequent content with contributions from some of the strongest participants in WagMedia, growing the production team to 8. The team is fantastically agile, able to push out high quality and up to date content, interviews, or Special Series such as the 19 video **[Polkadot Decoded Reloaded](https://youtube.com/playlist?list=PLtyd7v_I7PGlgPCXuIs55wwnbk594Kecw)** event. All content from the quarter can be found [here](https://www.youtube.com/channel/UCqNw3CEyOD-bjjYYaxVyG3Q/) and our **Proof of Work** including all research, rough work, references, SEO, and detailed [Spending Report](https://flying-wolf-8be.notion.site/Production-Funds-de4afb47625d48a9b4a5f0e74d074dff) is publicly available [here](https://flying-wolf-8be.notion.site/Q2-Content-Report-40b59b62222c46a6ac738359b8704b05).

Several Treasuries were also plugged into** WagMedia **over the last 2 quarters including Polka Häus, Jam’s Cave, Lucky Friday, Astar/Shiden, RMRK, Crust, Moonbeam/Moonriver, Solarbeam, Scytale Ventures, Bifrost, and the Kusama Treasury via Bounty #12. More are on the way!

In **Q3 & 4 **we are requesting to spend the same rates for content production with a slightly reduced output adjusted to market sentiment. We're also reintroducing a Tutorial show for when attention returns to the ecosystem as well as mastering our catalogue of [60+ interviews](https://youtube.com/playlist?list=PLtyd7v_I7PGkq7KUe3ep3lFLgKG97Z2AO) for distribution on popular podcast platforms. For each quarter we are requesting to spend aprox. 14% less than **Q2**

We are, however, for the first time additionally proposing to spend 14% of the requested **8002.8 KSM** on further developing **WagMedia** which endeavours to handle all content-focused tip and spending proposals previously put at the foot of the council. Goals over the next 2 quarters include, expanding our peer-reviewed translation and non-anglo community units, opening our Marketing department, and further decentralizing award distribution with the development of our bot, **The Concierge**. A proposal to top up **Bounty #12** to handle the Spend Proposal and Translation features (not part of the original curatorship) will follow [shortly](https://docs.google.com/document/d/1ZA2kmLxJyFbF5Xwa7dxdrK6b6F8Z8UbUiMoU-lBoMRQ/edit#).

For now please dive into T[he Kusamarian 6 Month Maintenance Proposal](https://docs.google.com/document/d/1_C34F07_LgY6DLgiXiLxbkMY_YH53if6esNhxXXYDG4/edit?usp=sharing) where you can meet our team, see what they propose to spend, and what they'll continue to build.

Thank you for supporting **Chrawnna Corp.** from a small tutorial youtube channel to what is today. We work every day to create top quality content in line with Token Holder interests with **The Kusamarian**. And with **WagMedia** we put the treasury to work by connecting it to eager content creators Decentralizing the Story of Dotsama within a productive and supportive community.

Your comments, questions, and constructive suggestions are most welcome.

The Kusamarian 6 Month Maintenance Proposal

Based on community requirements on the [Standard Guidelines to judge Liquidity Treasury Proposals](https://polkadot.polkassembly.io/post/951), this is an **external motion**: meaning it will be voted by council and community in order to be executed succesfully. 

________________________________________________________________________________________________________

In this proposal Equilibrium / Genshiro team aims to attract liquidity into Genshiro’s money market and DEX, incentivise KSM / EQD market liquidity and margin trading, further KSM network effects and benefit ecosystem with a first real margin trading and borrowing use case. Please follow the link below for the original post and proposal details:

Link to the proposal and original discussion post: [HERE](https://kusama.polkassembly.io/post/1630). 

 Liquidity funding proposal for Genshiro Money Market and DEX

RadiumBlock intends to be a Web3 infrastructure provider for DotSama. Since most clients that need to connect to the Kusama network rely on RPC nodes to interact with the network, we believe variety and high quality in the RPC service is important for a healthy decentralized network. 

This proposal is to cover the ongoing costs(Q2 2022) for the running of our low latency, geo-distributed, high performance, scalable, and reliable public infrastructure for Kusama.

Our [detailed proposal can be read here.](https://docs.google.com/document/d/1i0qCZTA9tL1zh7Z-cO_-aPaDJp88dyYy/edit?usp=sharing&ouid=114172945417100820622&rtpof=true&sd=true)

RadiumBlock Public Endpoint Service for Kusama (Q2 2022)

This is a treasury proposal whose proposer address (ES19ZE6CPEvQ1u8boRLL6XkWhiJTVZL3FUchParqARtN6Mu) is shown in on-chain info below. 
More information is available [here](https://docs.google.com/document/d/114HnCOFIQZ9ly8B0cQeIA_0XDsb3Xe_bGR7aavjAjSw/edit?usp=sharing)

Pendulum hosted an exclusive viewing event for the DotSama ecosystem as a part of the Polkadot Decoded program.
More than 400 attendees was expected from the DotSama space and were able to:
- Watch all Polkadot Decoded talks live-streamed on the screen
- Meet the biggest players of the DotSama ecosystem
- Attend additional Polkadot-themed talks and panels hosted by Pendulum
- Enjoy the coworking space, great food and beverages
- Join the afterparty with Berlin's DJs, drinks and more fun activities

The event was hosted by Pendulum and Eventbrite link can be found [here](https://www.eventbrite.com/e/polkadot-decoded-pendulums-viewing-party-tickets-367588064797)

Polkadot Decoded: Pendulum Hub Viewing Party Berlin

Encointer seeks for financing of its planned activities for the remaining time of its current common-good parachain lease, split into two proposals. The current proposal shall cover the funding until the end of September 2022. 

The amount of the proposed treasury spend is **CHF 340’000 = USD 350'892 = KSM 6271.63**.
*using [EMA50](https://kusama.subscan.io/tools/charts?type=price) and today's bid price for CHF*

Encointer has onboarded as a common good parachain on Kusama on Jan 9th 2022. In May 2022, a first real community in Zurich was launched and has steadily grown to 130 users within 40 days doing almost 800 transactions in community currency. More communities are in preparation currently

The main focus of Encointer is currently:

* to grow its Zurich community in order to prove the viability of its protocol and implementation as well as its economics with a pioneer community.
* to onboard new communities around the world, especially in less developed regions in order to follow its vision.
* to integrate with other parachains in the DotSama ecosystem for sybil-defense and one-person-one-vote democracy.

So far, Encointer was able to finance its past activities mostly thanks to the appreciation of the DOT and KSM tokens it received as web3 or DOT/KSM treasury grants. The association was also able to collect private donations and significant amounts of work were provided pro bono. Encointer’s financial strategy has been to keep around 70% of its capital in DOT and KSM which proved to be a good strategy so far, as our detailed numbers will show below. Due to recent market corrections, however, the runway of Encointer has dramatically decreased and Encointer can currently only maintain its current activity (development, operation, marketing, community building) for ~2 more months.  As a common-good, Encointer has no way to promise any return on investment, so the project relies on grants and donations.

See our [Proposal with full details](https://docs.google.com/document/d/1eTyZGCTCzo7ZGonVtAmJmc5QYYI0qYHab6z8w56B_F0/edit?usp=sharing)



Encointer Growth Treasury Proposal

The **ParisDotComm 2022** proposal is now up for vote! Note Please note that during submission, the team made a mistake on [treasury proposal 184](https://kusama.polkassembly.io/treasury/184) hence, a `batch` call to reject it and approve the subsequent proposal:

[Proposal 185 ](https://kusama.polkassembly.io/treasury/185) aims to fund the **ParisDotComm 2022** - a 3-day conference and workshop sessions organized by some of the leading projects of the Polkadot and Kusama ecosystems. The main goal of the event is to gather the Dotsama Ecosystem during the ETHCC 2022, to learn about the progress of Parachains and create new cooperation efforts between parachains and the blockchain world. On the proposal link above, you can find the additional information - including reasoning, agenda, and budget.

Make sure to review the proposal and vote at your convenience!


Treasury Proposal: ParisDotComm 2022 - a 3-day conference around ETHCC 2022

This motion is a `batch` call motion including three treasury proposals for community members who organised **side events during Polkadot Decoded 2022**: making the event even bigger! On each of the links below, you can find the reports for the events - including reasoning, agenda, budget and any recordings and photos on the event supporting the proposal.

- [Treasury proposal 180](https://kusama.polkassembly.io/treasury/180): funding proposal for Polkadot Decoded New Delhi edition event. The team successfully organized Decoded 2022 side event, with a gathering of over 100 people. Apart from showcasing online streams, the event also included speakers who discussed the basics of Polkadot and Kusama and discussions on the main chapters talks. The report can be found [here](https://kusama.polkassembly.io/treasury/180).

- [Treasury proposal 181](https://kusama.polkassembly.io/treasury/181): Side Event in Berlin, Germany (Happy Hour). This additional event was hosted by Acala, Astar, HydraDX, Interlay and Manta Network. 181 attendees discussed the latest developments in the Dotsama ecosystem at the end of the first day of Decoded 2022. The report can be found [here](https://kusama.polkassembly.io/treasury/181).

- [Treasury proposal 182](https://kusama.polkassembly.io/treasury/182):  Polkadot Decoded Event Viewing Party Juba. The team successfully organised a Polkadot Decoded 2022 viewing party on 29th and 30th June, with a gathering of 27 and 25 people respectively. The groups discussed the talks on the main events, which were either reproduced after due to timezone issues or watched live. The report can be found [here](https://kusama.polkassembly.io/treasury/182).

Make sure to review the reports and vote at your convenience!

Batch call Motion: reimbursing the Dotsama community on Polkadot Decoded 2022 side events

Kusama Runtime Upgrade to v9250

**Summary**

This proposal from Interlay aims to open an HRMP channel between Kintsugi and Statemine


**Details**

The technical details in this proposal are very similar to https://kusama.polkassembly.io/motion/418 but adapted for Kintsugi.. The weights and fee allowance have been copied from https://kusama.polkassembly.io/post/1744 - the weight used by most previous proposals is no longer sufficient. The main goal for this proposal is to allow currencies from Statemine to be used on Kintsugi as collateral for vaults.

As is usual for opening HRMP channels, the extrinsic consists of a batch of two calls:

A 11 KSM force transfer from Kusama treasury (```F3opxRbN5ZbjJNU511Kj2TLuzFcDq9BGduA9TgiECafpg29```) to Statemine (```F7fq1jSNVTPfJmaHaXCMtatT1EZefCUsa7rRiQVNR5efcah```) to pay for fees and for the deposit.
Send XCM message to Statemine to execute a transaction with superuser (root) permission.

**Relaychain preimage Data:** ```0x1802080402006d6f646c70792f747273727900000000000000000000000000000000000000000070617261e80300000000000000000000000000000000000000000000000000000b00b01723010a630001000100a10f0204060203009435779d011f000101000214000400000000070010a5d4e81300000000070010a5d4e800060003009435775c1802083c002c080000e8030000009001003c012c080000140d010004000101006d6f646c70792f74727372790000000000000000000000000000000000000000```

**Relaychain preimage Hash:** ```0xd8e1922b946a22f45ea223582130271f6c5bf73dbc469c1c0bff243aad39a14e```

**Relaychain preimage url:** [polkadot.js view](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x1802080402006d6f646c70792f747273727900000000000000000000000000000000000000000070617261e80300000000000000000000000000000000000000000000000000000b00b01723010a630001000100a10f0204060203009435779d011f000101000214000400000000070010a5d4e81300000000070010a5d4e800060003009435775c1802083c002c080000e8030000009001003c012c080000140d010004000101006d6f646c70792f74727372790000000000000000000000000000000000000000)


The call above will execute the following on Statemine:
**Statemine xcm call Data:** ```0x1f000101000214000400000000070010a5d4e81300000000070010a5d4e800060003009435775c1802083c002c080000e8030000009001003c012c080000140d010004000101006d6f646c70792f74727372790000000000000000000000000000000000000000```

**Statemine xcm call Hash:** ```0x9a427a849d70d4f2e4b105ed211f14e9b9a27eaee7cde2c1db8aecc9c0a24263```

**Statemine xcm call url:** [polkadot.js view](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fstatemine.api.onfinality.io%2Fpublic-ws#/extrinsics/decode/0x1f000101000214000400000000070010a5d4e81300000000070010a5d4e800060003009435775c1802083c002c080000e8030000009001003c012c080000140d010004000101006d6f646c70792f74727372790000000000000000000000000000000000000000)

Open HRMP channel between Statemine and Kintsugi

Including here the explanation behind the open tips for translations I have decided to kick off in the last days, given some questions were raised on the Direction Channel. 

The open tips are for work done on translations for Wikis, Polkadot light paper, website and blogposts, all done in the past months.

The volunteers translating the materials were part of the Polkadot Ambassadors Program. These tips are retroactive for the work done. The reason why in some cases there are more than one open tip for one language (in this case Turkish) is because a group of ambassadors worked in the translations together, so we take into account all of them for the tips. You will find some of them have an identity linked to the address and some don’t: I worked with W3F to track them down and get the addresses in order to open the tips. Please consider endorsing if you re a council member.

Regarding the different amounts: some council members raised the question of why the amounts differ so much - the amount of work and resources translated were not the same, I tried to evaluate the amount of work per volunteer and endorse with an amount that tries to reflect this (while some only translated website, others also translated wikis, blogposts, among other things, so the amount should be different).

Sometimes it is not possible to link an identity to an address for some users. However, as stated by JAM, we should all agree on a standard on how to handle tips that are linked to an anonymous address. Other options, like the ones suggested by him in the channel ("...put a tipping address in your readme/tweet/comment and link to it in your reason") might work for some but not for all, happy to open this discussion. 

On the latest tip proposals and on identity standards for tips

Super excited to present to the Direction channel the work developed by  the **Bright Inventions** team! 

Project Link (now in production) : [https://treasury.bright.dev](https://treasury.bright.dev)

BrightTreasury is a standalone web application along with a PWA representation that allows performing actions on the Treasury module of Polkadot and Kusama Substrate networks (with a potential to support **any Substrate-based network** with Treasury module). It allows a more intuitive and lightweight flow of submitting proposals as well as an overview of the Treasury related actions.

The main needs that were brought up to develop this:

* The need of a more intuitive proposal submission flow, with clearer indication of a proposal idea being subject to the community discussion, before submitting on-chain and committing with bond funds;
* One place for following the submitted proposals, their status and the results of motions;
* A unified discussion forum to leave comments about submitted treasury proposals as well as their draft versions (ideas);
* Implementation of the new bounties funding mechanism.

The development of this project was funded by the **Web3.0 Foundation Grants Program**, and the team plans to submit two proposals to treasury soon: 1. Costs and maintenance coverage proposal, 2. a proposal to include new features, and a two-way integration with Polkassembly (at the moment only Polkassembly info is shown on the dashboard, but if a user includes contextual information for a proposal on this new dashboard, it won’t be integrated to Polkassembly). 

Try it out! The team will add new functions and needs your feedback as well!

BrightTreasury: is a standalone web application that allows performing actions on the Treasury module

It is everyone's expectation for the community to welcome new Registrar candidacies aiming to decentralize the role as much as possible. Given the last discussions regarding this type of proposals, we expect those who want to become Registrars to explain their intentions and plans beforehand, and once the proposal is in the queue ask the community to second it to move forward to the referenda queue. 

Make sure to be active on all channels and talk to your council members and the community in general about your proposal. To do this, share this information on the Kusama Direction Channel and on any of the forums available for the Community.

In order to keep candidacies organised and **to make sure the community has full information**, we encourage all candidates to follow these recommendations:

- **Registrars should be known:** some kind of identity linked to the address should be available for the community to communicate with the proposer, and at least two communication channels should be in place in the on-chain identity for a registrar to show availability.  

- Registrars should publish what the **requirements are for the judgement levels available** and what the registrar fee is.

- Specifics on infrastructure used (in particular backend architecture and any custom code) should be published and kept up to date. The candidate should explain the code and design on the proposal, if any. **There should always be room for differentiation: ** innovation is always welcomed, but remember a price-sensitive strategy can also be attractive to the community. A Registrar should know what differentiates their approach from others.

The Registrar's design should deliver efficiently. 

- The proposer should **provide timely responses** to the community in the Kusama Direction channel or in the forum where the discussion is happening, as well as make sure that communication channels on their on-chain identity are up to date. 

It is essential for a Registrar to respond fast in the eventuality of a blacklist event **if needed**: for this, efficient communication is important to the role.

- **Registrar should prove some kind of experience** related to the candidacy and involvement in the community. Explain in your proposal what is the reason for your candidacy, in which way have you been involved in the Kusama Community up to now, if any, and what is in your perspective the role of the Registrar. 

Check the Kusama Wiki page to learn more about how to [become a registrar](https://wiki.polkadot.network/docs/en/mirror-learn-identity#registrars) and [how to set an identity](https://wiki.polkadot.network/docs/en/mirror-learn-identity#setting-an-identity).


Expectations for Registrar Candidates on Kusama Network: Some Recommendations 

Tip proposed for introductory video to Kusama Network to non-technical people in the Russian Polkadot Community, including:

- What is Kusama?
- Purpose of the network
- What are parachains, reasoning behind it and which teams are already building on Kusama. 

This tip complements the first one for the same content creator on Kusama validation and nomination process.

Tip for introduction and education on Kusama (2)

The Direction Channel has been discussing the idea of updating the staking rate compared to floating rate. When it comes to staking rewards and the ideal amount staked, we have generally kept to the idea of a 3:2:1 ratio between amount to be staked, amount to be locked up in parachain deposits and amount of float (not locked at all). In terms of percentages, this is 50:33:17 by design, so we target the "ideal" amount to be staked as 50%. 

**The problem**

Since there isn't any parachain functionality enabled currently, the amount for parachain deposits (33%) **has been accidentally aggregated** into the floating rate, making an overall float of 50%. **This in practice means that anything staked beyond 50% results in a reduction of staking rewards**, affecting rewards and treasury funds immediately.

**The design behind it**

The conclusion of the team behind the design was that the 3:2:1 ratio would provide a good balance between network security, float (price discovery) and parachain deposit cost.The intention of the 3:2:1 ratio was, in part, to recognise that only a relatively small proportion of KSM needed to be floating, **and this is clearly failing at the moment**. 


While there is no possibility of KSM being locked under parachain deposits at the moment, the options to maintain network security stable are: 


1. The 33% assigned to the floating rate to be entirely under the staking banner (in which case the new ratio would be 83:17, staking:float) 
2. Split it proportionally between both staking rate and floating rate (in which case it would be 75:25, staking:float). 


**No specific conclusion was made by the team on what should be done in the case that no parachain auctions/slots exist**, but researchers stated that floating tokens represent a theoretical risk that they could be used against the rest of the stakers. 

**The first consequences of the update**

The immediate consequence of this change would be:
 
- a decrease in treasury deposits,
- an increase in staking rewards. 

This could also incentivise security on the validators side and an incentive to think about validator reliability. Most of the Council seemed to agree on the idea of increasing the "ideal" amount to be staked, with the condition to discuss the implications of this in the economic design. Ultimately, the ratio should change automatically based on how many parachain slots are available for rent, but it's unnecessary until the first auctions happen.

After agreeing in the need to update, the questions remaining are regarding the type of referendum to take place:

- With what kind of referendum should the update happen with? (positive turnout bias, negative turnout bias or straight majority) - for more info their differences, please check [here](https://wiki.polkadot.network/docs/en/learn-governance#tallying)
- duration of the referendum

The opinion changes depending on how the discussion unveils regarding voting participation, time to get informed and vote, and so on. 

The discussion is ongoing and the expectations are to conclude this with a referendum that will enable the update. It's important for validators to participate in the discussion to agree on the specifications of the proposal. 

We are now focusing **on the 4 remaining questions discussed above**:

1. Should the 33% assigned to parachains be entirely under the staking banner (in which case it would be 83:17, staking:float)?
2. Should the 33% assigned be split proportionally (in which case it would be 75:25 staking:float)?
3. With what kind of referendum should the update happen? (positive turnout bias, negative turnout bias or straight majority)
4. What should be its duration?

Current work: https://github.com/paritytech/polkadot/pull/1302/commits


Discussion on the ideal amount to be staked in Kusama Network - first approach to an update.

With the last 10 auctions happening on Kusama, the community should think about the next schedules to come for the network to be truth to its goal: being the canary network in the ecosystem. 

When thinking about this schedules, there are a few things to take into consideration:

- Kusama is working well with a large number of paras, so it seems we can speed up on Polkadot's schedules.
- For Kusama, **the first batch of 5 parachains will end their leases on LP20. Then the second batch of 6 will end on LP22**. Currently we have 5 auctions scheduled per lease. A short term solution is to have 5 auctions for LP21, 6 for LP22 and further: but that is still not going to be a good solution for all chains: meaning we are not going to have more parachains because existing ones will want to renew lease. **6 auctions per lease could be helpful**: We will have 4, 5 or 6 for previous parachains to renew, some more for new parachains (adding new parachains doesn't mean one of the existing parachain needs to become a parathread).

All in all, two points need to taken into account for both Kusama and Polkadot:

1. Always have Kusama move forward faster than Polkadot in auction numbers;
2. Make sure current parachains have an opportunity to renew the slot.

Below you will find the current schedule and a proposed one to follow - take into account that dates and times are expressed in UTC.

## Current Schedule, enacted by [motion 384](https://kusama.polkassembly.io/motion/384):

10 auctions scheduled are left:

5 to be held during LP19, onboarding on LP20 (Start: 20 Feb 2022)

1. 20 Feb 2022 - block #11,491,800
2. 28 Feb 2022 - block #11,592,600
3. 07 Mar 2022 - block #11,693,400
4. 14 Mar 2022 - block #11,794,200
5. 21 Mar 2022 - block #11,895,000

5 to be held during LP20, onboarding on LP21 (04 April 2022)

6. 04 April 2022 - block #12,096,600
7. 11 April 2022 - block #12,197,400
8. 19 April 2022 - block #12,298,200
9. 26 April 2022 - block #12,399,000
10. 03 May 2022 - block #12,499,800

Leases are 48 weeks long.

## Proposed schedule for Kusama:

In order to allow existing parachains to renew while new chains onboard, **the first step** is to replace the last 5 auctions scheduled for LP21 and replace them with the following schedule:

![](https://i.ibb.co/pzgXFb5/1.png)

By replacing the current schedule for LP20 for the one above, **we ensure that those parachains ending their lease on LP20 can participate in a new auction to onboard on LP21**, and add two more auctions for new parachains that want to participate. 

## Kusama Target for the new schedule:

**30 new auctions** by the end of the year - dates approx:

1st Batch:

![](https://i.ibb.co/Wfm757P/2.png)

2nd Batch:

![](https://i.ibb.co/Wf6kC6h/3.png)

3rd Batch:

![](https://i.ibb.co/HKdWNZ5/4.png)

4th Batch:

![](https://i.ibb.co/KDJ8Xqk/5.png)

5th Batch:

![](https://i.ibb.co/THwGpv3/6.png)

**Auction design:**

- **Duration**: 27,000 blocks (45hs, 3hs overall - time for the winner to be picked). 
- **lease_period_index**: LP22, LP23, LP24, LP25, LP26.
- **threshold**: 13 / 19 council (greater than 2/3)
- **Ending period**: will be an additional 5 days (this is hardcoded on-chain)

**Considerations**:

- Auctions of 7 days long each;
- Chains onboarding on the next LP (ensuring full period for projects) with the expectation of the first 3 auctions per lease, this will allow having at least 3 previous parachain to renew and some more for new parachains;
- This would cover 6 auctions per LP.

## Call Design

```
utility.batch(
	calls: [
		// First, we need to cancel the set of auctions for LP21. We'll replace
		// them with a new schedule.
		scheduler.cancel_named(
			id: 'Auctlp21'
		),
		// First 5 auctions, for LP21. during LP 20.
		// LP21 starts on block 12,700,800, estimated 15 May 2022
		scheduler.schedule_named(
			// Auction ID
			id: 'auctlp21',
			// Start block of first scheduled auction
			when: 12_197_400,
			// How often to start auctions, and how many of this config to hold
			maybe_periodic: (100_800, 5),
			// Top priority
			priority: 0,
			// The auction configuration
			call: auctions.new_auction(
				// Opening period of 27,000 blocks
				duration: 27_000,
				// The first (of 8) lease periods for bidding
				lease_period_index: 21
			)
		),
		// 3 more auctions for LP21. during LP 21.
		// LP21 starts on block 12,700,800, estimated 15 May 2022
		scheduler.schedule_named(
			id: 'auctlp21r2',
			when: 12_701_100,
			maybe_periodic: (100_800, 3),
			priority: 0,
			call: auctions.new_auction(
				duration: 27_000,
				lease_period_index: 21
			)
		),
		// Now for our regularly scheduled programming...
		///
		// 6 auctions for LP22
		// LP22 starts on block 13,305,600, estimated 26 Jun 2022
		scheduler.schedule_named(
			id: 'auctlp22',
			when: 13_003_500,
			maybe_periodic: (100_800, 6),
			priority: 0,
			call: auctions.new_auction(
				duration: 27_000,
				lease_period_index: 22
			)
		),
		// 6 auctions for LP23
		// LP23 starts on block 13,910,400, estimated 07 Aug 2022
		scheduler.schedule_named(
			id: 'auctlp23',
			when: 13_608_300,
			maybe_periodic: (100_800, 6),
			priority: 0,
			call: auctions.new_auction(
				duration: 27_000,
				lease_period_index: 23
			)
		),
		// 6 auctions for LP24
		// LP24 starts on block 14,515,200, estimated 18 Sep 2022
		scheduler.schedule_named(
			id: 'auctlp24',
			when: 14_213_100,
			maybe_periodic: (100_800, 6),
			priority: 0,
			call: auctions.new_auction(
				duration: 27_000,
				lease_period_index: 24
			)
		),
		// 6 auctions for LP25
		// LP25 starts on block 15,120,000, estimated 30 Oct 2022
		scheduler.schedule_named(
			id: 'auctlp25',
			when: 14_817_900,
			maybe_periodic: (100_800, 6),
			priority: 0,
			call: auctions.new_auction(
				duration: 27_000,
				lease_period_index: 25
			)
		),
		// 6 auctions for LP26
		// LP26 starts on block 15,724,800, estimated 11 Dec 2022
		scheduler.schedule_named(
			id: 'auctlp26',
			when: 15_422_700,
			maybe_periodic: (100_800, 6),
			priority: 0,
			call: auctions.new_auction(
				duration: 27_000,
				lease_period_index: 26
			)
		),
	]
)
```


We ask the community to leave feedback and ask questions on the schedule above!

Kusama 2022 Parachain Auctions - A Proposal For Next Schedules on Kusama Network

We'd like to revisit the idea of **Recurring Payments**. 

This idea is basically a call that sets up in motion repeating payments following certain conditions. It would keep funding it from the treasury until there was a motion to cancel it or until the treasury runs out of funds. The logic will be similar to a vesting function. 

This could potentially be used on social contract designs for maintaining services on Kusama, to maintain the contract onchain after offchain discussion on agreement conditions. The call should be approved and cancel by the council, only to be submitted by a motion.

We'd like to open the discussion here for the community to add to the original idea. After, we will move on to the implementation of the call, if the community agrees. 


Recurring payments: an idea for maintaining services in Kusama.

[Motion 384](​​https://kusama.polkassembly.io/motion/384) and [motion 438](https://kusama.polkassembly.io/motion/438) scheduled auctions from LP16 to LP26: up until January 2023. In the last weeks, teams have identified and reproduced an issue with networking causing [parachain block time degradation, especially since v0.9.16 on Kusama](https://github.com/paritytech/polkadot/issues/4911). After analyzing the information from collators on different chains, the team concluded:

1. Block production overall has dropped by around 35-40%;
2. 0.9.16 on validators hurt, and on collators even more so;
3. 0.9.17 on validators helped with collation metrics but not with actual block production;
4. 0.9.17 on collators hurt collation metrics but seems to have improved block production slightly again;
5. The amount of collations produced has dropped by about 33%;
6. The proportion of collations advertised to validators has dropped about 15% and the proportion of 
7.requested collations out of those advertised has dropped another 15%. 

All in all, the team believes that there are issues in collators either discovering or connecting to validators and validators having trouble propagating information in a timely manner. The conclusion seems to be a bottleneck in networking on Kusama **that will worsen if more chains connect to the network without proper optimizations**. The team is fixing the identified issues and this will likely improve things. However, given auctions are scheduled up to January 2023, some extra assessment is required on our side to give as much time as possible for the optimizations to happen.

The below graphs show the issues explained above and experienced by many parachain teams with regards to block times on their chains - we show Statemine numbers below, but other teams can add their examples on this post:

![](https://i.ibb.co/dM7bt27/Screenshot-2022-03-23-at-09-19-21.png)

Current experienced block times, this should be flat at 12s.

![](https://i.ibb.co/Yps7zm2/Screenshot-2022-03-23-at-09-20-54.png)

Transition to the "Network Bridge Subsystem", in normal operations this should be in the order of magnitudes of a few dozen us.

![](https://i.ibb.co/VTGKLjW/Screenshot-2022-03-23-at-09-21-44.png)

This is a subsystem connected to the "Network Bridge Subsystem", which is congested; the above is one of a few reasons the times that should be in the order of 100s of milliseconds are exploding into the range of seconds (y axis is in seconds).
__________


As a consequence of these delays more messages are considered invalid due to view updates, which essentially causes the block degradation times and the bottleneck experienced in networking. 

## What To Expect

As the canary network of Polkadot, Kusama is alive to push the limits of what this technology can do: we expect chaos on-chain and it is the goal to engage the community for the canary network to serve the development of Polkadot. After analyzing the current [auctions schedule](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/democracy/dispatch) and with current leases expiring for some chains, here is how the parachain count looks over the rest of the year:

![](https://i.ibb.co/X3MnSkF/Screenshot-2022-03-23-at-09-23-05.png)

We are currently in LP19 and two new parachains will onboard in LP20 (making paras count increase from 27 to 29).  With the current plan for existing parachains to renew their slots, the next significant increase will happen at the end of June (making paras count increase from 29 to 35). The team aims to use this time to work on optimizations that will fix the issues seen on-chain and the situation should be reassessed by the end of April.

If, by the start of LP22 auctions in mid-May there are no performance improvements, the team will propose a reduced auction schedule to limit the growth of the number of parachains on Kusama. The amendment of the schedule enacted by [motion 438](https://kusama.polkassembly.io/motion/438), to be replaced by a slower version of it, which should aim to: 

1. Replace the current schedule and pause the onboarding of new chains, 
2. Allow enough auctions in future LPs for existing ones to renew. 

Kusama is fulfilling its purpose of showing current limits before optimization. In order to greatly push those limits we need to keep things stable so the team can focus on getting a major scalability feature called **asynchronous backing** done. With asynchronous backing, performance will no longer be about liveliness of parachains: this paves the way for resuming pushing limits and more optimization work.

We want to hear your feedback to keep pushing Kusama's capabilities, leave your comments below!



Issues with networking causing parachains' block time degradation - a possible approach

Opening this post to read your thoughts on the parametrisation of the bounties proposal. I am summarizing below the few opinions read over the weekend in Kusama Direction - please add yours to this thread. 

In general:

- Bounties should span longer periods: the original specification was intended as a governance budget to earmark/budget future expenses. Such budgets should in principle be able to span up to period of a year (or longer but that sounds like a nice upper bound for now). Furthermore, the Council gets to approve everything, so it’d be nice to not be too prescriptive 

- Taken the below into account, bounty duration in the current design is basically just a required heartbeat duration and it doesn't actually describe how long the bounty lives unless the curator disappeared - in the current design you can extend the bounty if needed. 

Parameters: https://github.com/paritytech/polkadot/pull/1336/files

Original treasury pallet extension discussion post: https://kusama.polkassembly.io/post/86 

On Bounties Spending parameters -  A Summary 

I have been working on a proposal focused on Community growth and education, involving the KSM Society and [DotsToLines](https://www.dotstolines.com/). I am adding a link to the proposal, the narrative, rationale, milestones and goals here for your review and discussion - happy to answer questions. I have not included the projected budget for the proposal for now to focus only on the content, and will be sharing this shortly. 

You can find the proposal [here](https://docs.google.com/document/d/1IX0PH1xUmbnJCY_eN-HSr-_a863FeQdXXMnwpzIL4l8/edit?usp=sharing).

**THIS IS AN ALLIANCE BETWEEN HUMANS AND MACHINES.** We are a product of science and technology, we cannot distance ourselves from it. We can forge an alliance to embrace what technology can do for us and what we can do for others. 

**We are part human and machine.** We are part of hybrid networks living and reproducing in our bodies. The dichotomy Natural / Artificial is no longer relevant in our times. We are here to understand how hybrid networks can help human development. We are cyborgs. 

**The Kusama Human Blockchain** Project aims to forge an eternal alliance between human and machine. We live in the machine and the machine lives in us. This is a social movement **triggered by the immutable hash-chain as a concept with the goal of erasing the division between human and machine**.


DotsToLines - KSM Society Collaboration: The Kusama Human Blockchain Project

**CONTEXT**

Kusama currently has three governance bodies:

1. The assembled stakeholders, as weighted by KSM controlled as well as KSM locked into the future. 
2. The Kusama Council (who control the treasury and half of the legislative agenda) 
3. The Polkadot Technical Committee (who are able only to fast-track proposals) 

This is a proposal kick off for a new body: **The Kusama Supreme Oracle.**

**This is a membership group of people with an objectively high degree of professional or social standing. Examples would be academics, journalists and lawyers, though other professions may also be reasonable.**

** PROCESS AND COMPOSITION**

A small number of current group members (3-5) would be tasked with verifying the identity and the objective measure of professional standing for them (likely through a government-issued ID over video-link and using some professional score such as H-index). The identity of outgoing members is revealed publicly, to ensure that these identity verifications can later be vetted. The temporary anonymity is to protect against physical/online intimidation. The set of members would be paid weekly and re-elect itself monthly from a queue of people prioritised according to the objective measure of professional/reputational standing. 

**FUNCTIONS**

**The body acts as a kind of “supreme court” or oracle of last resort, allowing—for a small price—a statement grounded in physical reality to be evaluated with a high degree of confidence that any resultant answer would be correct.**

The purpose would be to **allow objective statements drawing upon real-world concepts** (and thus not suitable for on-chain determination) to be judged as being accurate or not (or, perhaps, indeterminate)

The four potential initial use-cases that seem valuable:

1. A grand oracle that could act as a judge of other, lesser staked, oracles,
2. Enforcing treasury spending regulations (i.e. council or subcommittee spending),
3. Enforcing a general constitution (i.e. on any governance activity, even referenda),
4. Judging governance actions (in particular upgrades) to enforce and automate council members manifestos.

**PENDING TASKS FOR DISCUSSION**

1. Funding: how will experts get paid? What are the options we have in mind? 
2. Get the first experts to be the first few initial oracle members: how and who to choose?
3. UI integration, maybe structured along a bounty or treasury proposal.
4. Extension of tasks to other areas of the network.
5. Decide on members' rotation and composition.


The Kusama Supreme Oracle

"hi all! I'm the lead designer on Sunshine (https://sunshine.foundation) we have a grant proposal I was hoping to get some feedback on 🙂. We are hoping to build a grant and bounty aggregator as a first step toward our on-chain platform with support from kusama. The details of the proposal are here: https://hackmd.io/@sightnoah/ByHn49mlv thanks!!"

From Noah Gallant from Sunshine Foundation - New submission: Sunshine Alpha Interface, build a grant and bounty aggregator for Kusama Network

With Bounty spending implementation approaching, we have gathered some ideas from Council members and the Kusama Community related to what the first use-cases might look like - you will be able to find a first iteration [HERE.](https://docs.google.com/spreadsheets/d/18LSWguM1EqUIdzZWJlLcfUdyO9NtfSiWwKbZ1oh1Tl0/edit?usp=sharing)

The document includes a first draft on **Categories** on its first tab (not final of course) and a second tab including some of **use-cases**. 

Please **comment or add yours here** to be listed and create an organised funnel with the first bounties. 

Bounty spending first use cases: some ideas

Kusama Network should focus most of its resources on encouraging experimentation with the technologies developed by Parity, the Web 3 Foundation and the community of Substrate developers. **At the moment, developers are a scarce resource on a rapidly changing network like Kusama.**

In order to scale and develop new ideas for the Network, we are searching for developers that are interested in joining our cause. The group, called "The Kusama Devs Team" should be interested in working on valuable projects, as directed by the Council and guided by part of it, in the form of a bounty or any other set up to be confirmed, treating these at first as side projects in exchange of KSM rewards. 

**The plan envisioned involves two steps:**

A. Start a call for those who want to join, form the group with the first developers and start right away with the ideas to scale on feature tasks and show differentiation of Kusama Network. The first projects we plan to set up for work are: 

1.  an implementation of a data feed to be potentially added to Kusama runtime (in process - more to be shared soon), 

2.  [Kusama Supreme Oracle project](https://kusama.polkassembly.io/post/171),

3. [Recurring Payments Mechanism](https://github.com/paritytech/substrate/issues/6551).


B. The second part of the process is to set up a **"Kusama Social Security Program"** for those joining the team. Besides the KSM rewards for working on new features received by developers who join the group, the developers will receive on specific accounts an X amount locked in KSM on a periodic basis as a recognition for being part of the team. 

These tokens, locked for a specific period of time to be defined, will be able to be used once certain conditions are met, can be a specific time, specific number of tasks developed, voting by the Council or by part of the team. 

On the idea of a **Kusama Social Security Program**:

- This small ongoing payment to accounts can be stopped at any time by the Council or if that account stops taking bounties it would probably not be spendable, but rather a reserved balance to be unlocked after certain conditions are met. 
- When developers leave on certain terms, the account would get unlocked. These could also be unlocked after a period of time has passed: maybe monthly, so it functions almost as a kind of "sick pay" mechanism. 
- For those developers who prefer a more stable, employee-like job relationship, this program might give them the security they need under certain terms.

We are eager to hear your input on these ideas to work on a first iteration of the second point. The team is already forming and we are looking forward to count with Kusama Dev force to help us bring Kusama further. 


Scaling up our efforts on Kusama Network: The Kusama Dev Team

As you all know, we have been working on Bounties for a few weeks now. The final stage has come and we are now in the final benchmarking and testing period, and after a final review the code will be merged and added to one of the next runtime upgrades.

As it is now, and given some technical difficulties discussed, we have decided to take a gradual approach to the bounties development. In this sense we introduce a **two-step approval mechanism**:

- First, the Council approves the bounty allocation.
- Second, the Council decides on a curator to take the role for the particular earmark: once the curator accepts the position offered by the Council, the curator makes a deposit. The deposit can be used to punish them if they act maliciously, but if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back along with part of the bounty as a reward (the curator fee).

This mechanism allows the Council to delegate responsibilities and the Curator to be held accountable. Certain limits are set in place with the goal of avoiding bad behaviour: the Council is allowed to cancel any payment during the delayed payout period (the period between bounty being awarded and the reward being claimed) or unassign the curator to the earmarked funds if they do not fulfil expectations. But when the bounty is active, **ONLY** the curator can cancel it.

**What's to come:**

To increase complexity in a gradual manner, we are adding sub-bounties in the next PR in the exact way as discussed in the Direction channel a few weeks ago. Sub-bounties will allow curators to divide tasks and work with different teams as needed.

Sub-bounties added a lot of complexity to the code that needs to be tested first with simpler use-cases. Practically speaking, they can be practiced off-chain for now until familiarity with the code is reached and the new PR is ready to be pushed.

On the PR, Sub-bounties will be just bounties with a link to the parent. What we will include is a depth in the bounty. We will include a track and a limit. We should have a limit on the amount of sub-bounties, a track to link to parents (to know what belongs where) and a cap on recursion to 1 (to avoid dividing a bounty into infinite levels and becoming a PM nightmare).

You can find below a diagram with the current flow to understand better. This will be updated once sub-bounties are in place:

![](https://gateway.pinata.cloud/ipfs/QmXWPjrRubX6aqDqPSYXr1W8W8Udo43DknnGQnoKgb5XuR/DIAGRAM.jpg)

Current implementation : https://github.com/paritytech/substrate/pull/5715

Original idea: https://github.com/paritytech/substrate/issues/5713

A Final Check on Bounties' Development

A **new project proposal is open for discussion**: a reoccurring lottery system that can be used to drive participation on Kusama network: users who want to opt into this lottery can do so by calling the vote extrinsic wrapped in a buy_ticket extrinsic. While the specification of the system is still being developed, the discussion is open to questions and comments.

The original document can be found [here](https://hackmd.io/68rduBydTEy4X-ULevd90g), please add your comments or questions below! **You can find here a summary of the first discussions on the Direction Channel:**

- In general the proposal is appealing to the community, as it tries to improve a key issue in Kusama Governance: participation, both in the community and indirectly, in the Council level. Linking the Lottery to steer behavior seems to be a good idea.
- A suggestion seems to be to allow more than one winner in order to increase incentivation, added to the idea that seed can always be configurable. On this manner, you can control participation incentives with the seed. 
- Some members suggested Polkadot JS Apps could have a switch to wrap (or not by default), improving UX and usage.
- Although this might not be a suitable mechanism to incentivise Council participation by Council Members, it might be an indirect way to commit them to participate on behalf of their passive stakeholders.  
- Shawn (proposer of the project) suggests an initial budget of 250 KSM for approximately 5 days of work (~2 weekends), and any additional budget can come from donations if people are satisfied with his work and timeliness.

Participation Lotteries on Kusama

Kusama is now operating at 500 validators slots. 130 validators are waiting to be included and the total stake percentage is 60,83% - as scheduled. If [Referendum 76](https://kusama.polkassembly.io/referendum/76) is not paused in the near future, there will be an increase of 2 validator slots per era for the next 283 eras. 

Find [here a full report](https://docs.google.com/document/d/1QT2dstt92q3pCo6CwtiyEQ28l-60eQUdY_XvmBlgt6c/edit?usp=sharing) of the scheduled task and its effects on network metrics, and some overall recommendations. 

It is advisable to monitor the amount of validators waiting to validate, as the number of validators slots increases. 

Referendum 76 & the 500 Validators Milestone in Kusama Network: Performance Report

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. 

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

After reaching the 600 validators milestone in Kusama, we are reviewing the metrics from [the 500 validators milestone](https://kusama.polkassembly.io/post/245) report for further steps, aiming to reach 1000 validators by the end of the year.  

The full report can be found [here](https://docs.google.com/document/d/1QmTEVoSLDL7j7smB0MYdpRHe6dZq548kH3zBpM7X19c/edit?usp=sharing).

**Recommended Steps**

- Closely monitor the minStake/AvgStaked ratio as we increase the numbers of validators. 

- Decide on an optimal value of the ratio for the network, to be used in the [automatic validator increase mechanism](https://github.com/paritytech/substrate/compare/shawntabrizi-validator-damping-function?expand=1) designed by the team.

- Closely monitor bandwidth and finality as we enable **Authority discovery**.

- Set up a plan to produce and distribute educational resources for new nominators focusing on what to look for when choosing validators. The resources should review the differences between nominating new/small validators and established ones. Furthermore, encourage validators to produce reports and for nominators to those use as signals of confidence when staking.

Performance Report II: 600 validators milestone, Kusama metrics and next steps

In the last days, and while we wait for some of the functions we discussed in the last weeks to be ready, we have been working on an idea that’s been recurrent among some of our community members: **A Validators Resource Center**.   The goal is to build a page focusing on validators information on Kusama Network. The website, to eventually live on https://kusama.network/ as subpage, aims to provide quantitative and qualitative data about validators’ performance and help nominators to choose the best nomination set that works for them.

The development of this project has 2 phases: we would appreciate your feedback and comments on it. A member of the Kusama Dev Team, Mario (the mind behind https://polkastats.io/) wishes to implement this once everything is defined and the work will be complemented with @Jonas from W3F, @will from Parity and my feedback.   

You can find a full explanation of the project [here](https://drive.google.com/file/d/1y7RVrAbDxl1z-qpG4kKvK-4Lj7zAK2Oc/view?usp=sharing).   

This project should be understood as part of the bigger goal of providing the community with as many tools as possible to make informed decisions (part of the 4th point on this [post](https://kusama.polkassembly.io/post/262))

Validator Resource Center and Ranking Website for Kusama Network

Kirill presented on **Decentralized Web Meetup #5** by CyberAcademy about Web3's vision/movement/process, the place of Polkadot in the web3 movement, and gave a brief overview of the surrounding tech and ecosystem on Kusama and Polkadot. 

For Kusama, he engaged in a game of "bounties" for answers and sent 4KSM in rewards. 

- You can find the talk [here](https://www.youtube.com/watch?v=83-Tpr3kEYI).
- Transactions:

1. https://polkascan.io/kusama/transaction/0xbbfe5df82d690d3423b890dec89dbe97219677faa704f921c0d3132bb320a4e0
2. https://polkascan.io/kusama/transaction/0x072c1ae1761198b2cfe2028dd5810217dce05ddbe31d0b9c9f5fc87e34eafe17
3. https://polkascan.io/kusama/transaction/0x52dbe33f538f70de39a19a7445ee92f9fd48d56552da4d5a0fe2c355a9f4be44
4. https://polkascan.io/kusama/transaction/0xfb964d71e99f90108785993e3aa0d127b14f1a4e9c6a393b6b4657433637d8b2



Tip to Kirill from Parity for reimbursement of "question bounties" during talk - educational efforts

We aim to introduce a non-fungible token (NFT) strategy for Kusama Network, with the goal of allowing users to experiment with non-fungible tokens in art, gaming and other applications. 

NFTs are unique items on the blockchain that serve a specific purpose or represent a specific real-world value, be it digital art, in-game assets, certifications, or even the concept of access (like a ticket to an event). Non-fungible token standards allow NFTs to move easily across heterogenous ecosystems. When a developer launches a new NFT project, these NFTs should be viewable inside dozens of different wallet providers, tradeable on marketplaces, and  displayable inside of distinct virtual worlds. This is possible because standards like EIPs provide a clear, consistent, reliable, and permissioned API for reading and writing data.

The focus is on implementing a **5 step strategy** that allows NFTs usability first on the relay chain with defined standards, with the support of NFT Pallet and RMRK.app: two solutions that can be deployed right away if combined with PolkadotAssetJS application. A second and third step include the development of [Unique Network](https://devpost.com/software/unique-network) on Kusama. 

- Amended strategy [here](https://docs.google.com/document/d/1hflIRKG207uuWkE13lZbFBaf6f4qF_3uvsctNoZFH0o/edit?usp=sharing)


An NFT Strategy for Kusama 

With [Referendum 89](https://kusama.polkassembly.io/referendum/89) passing on Kusama network, the network runtime is updated to v2025. This upgrade includes [Bounties extension] (https://github.com/paritytech/substrate/pull/5715) to the treasury pallet: something the community has requested and been working on for months. 

Now that we have reached this point: **What is next?** The first bounty use-cases should set a standard when it comes **1. Structuring a proposal, 2. Discussing it, 3. Electing a curator for it. **

## **Structuring a Proposal**

The bounty process introduces a two-step approval mechanism: the first step involves the Council approving the allocation while the second involves the Council deciding on a curator to take responsibility and ensuring that all tasks are properly executed.

For the first step, we have developed a skeleton of what the proposal could look like (similar to a Spending proposal) with some minimum requirements the Council needs in order to understand, assess and vote on bounty proposals: you can find the template [here](https://docs.google.com/document/d/1Hi9HWQ53yGec1vlan5adtwxRymjut3SULdrOMAi9jRg/edit?usp=sharing). **Your proposal does not necessarily need to look like this, but it should at least cover all points of the template.**

## **Discussing a Proposal & Electing a Curator**

After the Council approves a proposal, it's time to elect a curator: the Council can invite curators to accept the challenge of managing a portion of the treasury. If one of the candidates accepts they make a deposit that will be returned once the bounty is closed but slashed in case of curator's misbehaviour. The curator is expected to have a good track record related to the issues the bounty is trying to resolve. 

The introduction of curators allows the Council to extend their authority over a portion of the treasury. The treasury can have many active bounties and curators simultaneously. 

## **The First Use Case for Kusama Network**

In the last weeks, we gathered some ideas from the community about how to use this mehcanism once ready. All ideas can be found [here](https://docs.google.com/spreadsheets/d/18LSWguM1EqUIdzZWJlLcfUdyO9NtfSiWwKbZ1oh1Tl0/edit?usp=sharing). 

Out of all them, **building a bounty UI on Apps** is paramount for the success of bounties: without it, it would be difficult for users to understand how bounties work, what is their status and what are their functions. **This is the reason why we would like to suggest building a bounty UI** as a first use-case: design front and dev front are needed to develop and implement this. 

Development-wise, a new package/app would be added to [Polkadot Js Apps](https://polkadot.js.org/apps/) under the Governance tab. Before having this on Apps, we would already have at least one bounty (the one building the UI for the extension). The first deliverable, merged and deployed would display what is already on-chain. The next steps for the bounty would include the development of bounty submission buttons, close button, extend button, claim button and other functions as defined on the bounty protocol, timeframe of bounty, curator's identity and link to the proposal, among other things. By the end of the roadmap, a user should be able to make full use of the functionality to manage bounties and monitor status. 

It was suggested that the curator for this particular bounty should be Jaco, given his work and full commitment to Polkadot JS App. **The curator fee will be 0 KSM.** 

A formal submission for this bounty will be presented to council in the next days to open the discussion. Other use cases included on the sheet will be presented for discussion as well in the next days.

**This post is open to feedback, questions and comments regarding the extension and the first use cases.**

What To Expect Once Bounties Extension Is Here

At the moment, there is no way for users to see bounties on Apps: this development would greatly allow users to make use of the bounty extension. A first bounty for building a bounty UI on Apps, including design front and dev front needed to develop and implement the Bounty UI on Apps. The plan is for Jaco Greeff, given his work and experience, to be the curator of this bounty: however the curator will still need to accept the candidacy suggested by the Council. 

You can find the bounty proposal [here](https://docs.google.com/document/d/1bfjJ88xD4uR4ZXoRpchYWTuMGKeEexaWlutAkrbmWq4/edit?usp=sharing) - Feedback, questions, suggestions and comments welcome! After feedback the bounty will be submitted for council approval. 

Kusama's First Bounty Proposal: The UI bounty on Polkadot{.js} Apps!

The Ryabina team added a new set of notifications on their bot **to notify all stakeholders on Kusama and Polkadot about runtime upgrades and emergency situations via `remark`**. The call is triggered by the Parity team from a multisig wallet whenever a runtime upgrade is voted. 

Each time a message is ready to be sent, one of the accounts triggers a msg using `system.remark` that the bot will pick up to issue a message to those subscribing to the service. This messaging system complements newsletter emails notifying stakeholders of the changes, an essential part of the forkless upgrade processes in the ecosystem. 

Link to msg image: https://imgur.com/a/rCNe8lX 

Tip on Polkadot: https://polkadot.polkassembly.io/tip/0x9c73401e235df52679a28665a4f9edf16958d268ac84281a9491b0df68553cb8

Tip to Ryabina for add-ons on Ryabina Bot

With the v26 runtime being in polkadot, [a bug](https://github.com/paritytech/substrate/pull/7384) that caused immature slashing of candidacy bonds in council was fixed, and now's the time to proceed with refunding affected accounts. 

**Context And Problem**

In the `elections-phragmen` pallet, each candidate has a life cycle with 3 possible stages, namely Candidate, Member or Runner-up. First, accounts can `submit_candidacy()`, and the pallet will reserve `CandidacyBond`. If the account makes it into the Members or Runners-up list, then this bond is kept. Else, a loser candidate will always lose their bond (`slash_reserved()`). Moreover, members and runners-up must also `renounce_candidacy()` in time. If they lose their spot in an election round (i.e. no longer hold any role), they also lose their bond as the consequence. 

Due to an API confusion, we sometimes mis-calculated the outgoing runners-up, thus slashing them prematurely. Furthermore, we mistakenly slashed members and runners-up when they moved in between the roles.

This did not affect all accounts, but some bonds were taken by this error. The team discovered that the root of the issue was in the `election-phragmen` pallet. **The bug is now fixed in v26 (and 2026 in Kusama).**

We have gathered info about this in the last few weeks. Kian, from the Parity team, [recorded a short video](https://youtu.be/7tiGwqiaPZM) for transparency of what happened and how we intend to fix it. 

- A more detailed write-up about the event, including details of how the refund is calculated and can be reproduced: https://hackmd.io/HZVxUWuKTHSVHdjRVtwE0g
- Spreadsheet of current calculated refunds: https://docs.google.com/spreadsheets/d/1dHch86flQ-yXw-BJcnjWLqND2nxOcp4p-hppcuD_DqA/edit?usp=sharing

**Steps Going Forward**

1. **Discussion by the council**, questions and comments on the incident;

2. **Reimbursement of the affected accounts**: The reimbursement process can happen in two ways:

- Tipping from the treasury pallet: Opening one tip per user for the calculated amount and requesting endorsement by council members.
- Wrapping all of the reimbursement calls inside a `utility.batch`, creating a single batch of force transfers from the treasury to the affected accounts, to be voted by the community.


Feedback on the steps going forward is welcome!

Incorrect Slashing on Council Caused by elections-phragmen Pallet Bug

After reaching the 700 validators milestone in Kusama, we are reviewing the metrics from the 600 validators milestone report for further steps, aiming to reach 1000 validators on Kusama.

The full report can be found [here](https://docs.google.com/document/d/1bgekaVpfr3bd95KcVD9hHa1LWcxDKU-27u7Y3yxOU30/edit?usp=sharing).

Recommended Steps:

- A **gradual** increase in slots is recommended to slowly get closer to 1000 validators on the network, making sure QoS is closely monitored. 
- Closely monitor the `MinStake/AvgStaked` ratio as we increase the numbers of validators.
- Regarding our last suggestion on information access: A series of tutorials have been published to help nominators elect validators efficiently, along with a [Validator Resource Center and Ranking Website](https://kusama.polkassembly.io/motion/217) where nominators can find quantitative and qualitative data about validators’ performance and choose the best nomination set that works for them. Phase 1 of the Ranking is ready and can already be used [here](https://colm3na.github.io/kusama-validator-resource-center/) - Phase 2 to start soon. 

Performance Report III: 700 validators milestone, Kusama metrics and next steps

After many requests by users to integrate Kusama Network to [**Rotki**](https://rotki.com/), we have worked with the Rotki team on a proposal that aims to complete this, having a native integration in Rotki for Kusama: This means to have the Kusama blockchain at the same level of handling as Ethereum and Bitcoin for Rotki, allowing to account imports, balance queries, transaction querying and eventually staking information. 

Rotki is an open source portfolio tracker, accounting and analytics tool that respects your privacy. The mission is to bring transparency into both the crypto and traditional financial sectors through the use of open source. Most importantly, unlike virtually every other competing service which consists of closed source webapps onto which you are forced to hand over all your financial data, with Rotki your data is stored encrypted locally in your computer. **It enables you to take ownership of your financial data.**

More information on the proposal, timelines & allocations can be found [here](https://docs.google.com/document/d/1OwdIcrAqDxMpDcIRTE7wbJU0aO2gGfZplyEI7s1oWPo/edit?usp=sharing). 

Feedback is welcome!

Proposal: Native Kusama support in Rotki

[@shawntabrizi](https://kusama.polkassembly.io/user/shawntabrizi) has been working on the Participation Lottery Pallet, originally presented [here](https://kusama.polkassembly.io/post/242), for the past weeks. The original idea: a configurable, reoccurring lottery system that can be used to drive participation on the Kusama network, is now almost ready to be deployed. 

A participation lottery can be used to drive forward the following behavioural changes to the network by attaching a lottery to a specific extrinsic:

- Have more users share their voice on important elections. (`vote`)
- Have users change/update their validator nominations on a regular schedule. (`nominate`)
- Have more users join Society or other similar social experiments (`put_bid`)
- Encourage brainstorming of ideas in future updates and changes (`propose_bounty`)
- Have more users (change their) backing of (candidate) council members (`electionPhragmen,vote`)

You can find the original write up for the idea [here](https://hackmd.io/68rduBydTEy4X-ULevd90g).

The PR can be found [here](https://github.com/paritytech/substrate/pull/7221).

Please leave your feedback, comments and questions on this post! And remember to vote on the poll to the right: should the pallet be deployed and tested on Kusama?



Reopening The Discussion: Participation Lottery Pallet in Kusama

The Validators Ranking team will submit a treasury proposal to pay for phase I completed milestones of the Validators Ranking to Mario Pino, the dev in charge of the implementation. You can find the details of the proposal below:

- **Milestone 1** for the 1st phase of development was submitted on 23.09.2020 for the total amount of 95.14 KSM (USD 2,373.00 at the time) -  https://kusama.polkassembly.io/treasury/48 
- **Milestone 2** is not yet completed: JSON defined and form developed but identity remarks not ready yet to integrate, so this particular milestone is on hold until completion.
- This proposal covers **milestone 3, 4 and 5**: all completed (milestone 5 was added to the proposal in order to o implement polkadot js extension) - more details on the milestones can be found [here](https://kusama.polkassembly.io/post/302#4aec0342-d7a6-469a-af55-1dba66b10cdb) 
Completed milestones to be paid:

- Milestone 3: EUR 1,000.00
- Milestone 4: EUR 1,000.00
- Milestone 5: EUR 1,000.00

Rate: 37 EUR/KSM (based on 30 day Avg price)

**Total proposal: 3000/37 = 81,08 KSM **

Original proposal: https://kusama.polkassembly.io/post/118

Payment for completion of milestones 3, 4 and 5 of Validators Ranking (Phase 1)

**Phase 2 of the Validator Resource Center and Ranking Website (VRC)** further improves upon the ranking method from Phase 1, by making the scoring model more customizable and thereby better representing the user’s preferences. Also, the VRC score is now a major metric in the manual selection process. Additionally, we include several new metrics (e.g. performance based on historic era data) and thereby reduce the load of information on nominators. **A new filtering technique** helps to reduce the overall set of validators based on their quantitative properties and make it easier for nominators to make an appropriate selection. 

Aside from that, Phase 2 introduces a **staking dashboard**, which gives important visual and numerical information about the network, allowing comparisons of sets to the state of the network. It will be even possible to import your current nominations (via the polkadot.js extension) and check whether some critical events happened to nominated validators (e.g., an increase of commission or a slash).

You can review the full proposal [here](https://docs.google.com/document/d/14pvmbMMzNAqVzQkoXi_nRS-1wDti2y03X4VqOp9nNTw/edit?usp=sharing). Please leave your comments!

**Code-of-conduct for the implementation**

We are aware that this project bears a large responsibility towards nominators and validators. Therefore, every decision on this implementation follows these principles as much as possible:

- Act in the interest of the network as much as possible.

- Act in the interest of the nominator whenever possible.

- Objectivity on validators selection as much as possible. Don't discriminate against individual validators.

- We value user preferences and try to give them as much freedom as possible while maintaining the trade-off with usability.

------

A link to the last proposal can be found [here](https://kusama.polkassembly.io/motion/217).

Proposal: Validator Resource Center and Ranking Website for Kusama (Phase 2)

**Original code:** https://github.com/paritytech/substrate/blob/master/frame/lottery/src/lib.rs 

**Previous discussion:** https://kusama.polkassembly.io/post/242 
______________________________________________________________________________________



# Introduction

The Lottery Pallet is part of an effort aiming to increase participation in Kusama's governance design and should be understood in this context. The pallet interacts with Democracy, Collective, Staking and Elections-phragmen modules, by including the extrinsics within these as a mechanism to purchase a ticket for a lottery, upon certain conditions. 

The pallet can be linked to any calls in Kusama and Polkadot, but initially it is intended to be used in **validators election, council nomination** and **democracy referendum vote**. Although this might not be a suitable mechanism to incentivise Council participation by Council Members, it might be an indirect way to commit them to participate on behalf of their passive stakeholders. 

A disadvantage of the pallet is its vulnerability to Sybil attacks. However, this can be reduced by increasing the cost of participation in comparison to the cost of an attack.

# How Does It Work

A collective on Kusama (most likely the Council, at least on the initial phase) will open a lottery and decide on the calls to be included for participation. The Council starts a lottery by voting a motion that executes `start_lottery`. In the motion design, the Council also votes on the included calls (`set_calls`), by adding the call indices to the proposal, or programs the valid calls directly into the runtime (which is what we might want to do in order to have strong control over valid calls). The motion also includes the price of the ticket (an estimation for the initial phase is to set this up at 0.1KSM), the lottery length (initially 1 month has been discussed), the delay length (allowing the mechanism to be resistant to malicious actors) and if the lottery will repeat or not after end block is created.

Once the motion passes, the lottery is opened, including an `index` for identification and an address, similar to the Society pot and the Kusama treasury. The lottery will have its own address and a positive balance, funded by lottery ticket payments by users when purchasing one and any other discretional donations to the mechanism.

**Some considerations when purchasing a ticket:**

A ticket can be purchased by executing any call included as `validCall` in the proposal. An address can purchase one ticket per valid call: this means that, if three calls are included in the design of the lottery, an address can purchase **3 tickets**. The pallet includes a mechanism that checks for address participation before confirming purchase (`AlreadyParticipating`). 

There can only be one lottery per period, but the design includes the option to repeat the same lottery (this option needs to be approved by the Council when voting on the proposal). The Council can also cancel any repetition or create a new lottery with different parameters. We mentioned a **0.1 KSM price per ticket**: this price is not fixed and can be adjusted whenever a new lottery starts, but only at that granularity: to change the price, the Council would need to cancel the repeating lottery and start a new one at the new price. 

New calls can be added dynamically if storage is used to do call validation. In order for a ticket purchase to happen based upon certain conditions (i.e: only democracy votes of a certain value qualify to purchase a ticket) this would require a runtime configuration and therefore an upgrade of the network.

In order to make it easier for the user to interact with the pallet, some changes in the UI are needed: a "**Buy Lottery Ticket**" button (enabled when a lottery is active and the call is valid) should appear on the extrinsic approval screen for users to have the option to participate. 

# The Lottery Is Open: What's Next?

Once the lottery is open, users can purchase tickets by signing those calls included as `valid`. In an hypothetical lottery in which the `validCalls` are:

`Democracy > vote(ref_index, vote)` - vote in a referendum
`ElectionsPhragmen >  vote (votes, value)` -  Vote for a set of candidates for the upcoming round of validators election or council members

any user signing these calls will have the opportunity to purchase a ticket for the period of the lottery and can only do this once per call. When the ticket is purchased, users become lottery participants and need to wait until the lottery ends to know who the winner is. 

The length of the lottery is defined by block numbers: once the end block is created, the lottery will go to a delay period, to be defined in the proposal. After, randomness in the "payout" block will be used to determine the winner, meaning **the system will randomly choose a winner from among the total number of participants**.

# FAQs

- **Does the pallet limit address participation so an address can only participate once? Can an address participate in a lottery more than once by calling different valid calls? or is this limited by `AlreadyParticipating` as well?**

- Users can buy 1 ticket per valid call. So if there are 3 calls, they can get up to 3 tickets for a single lottery.

- **Does the lottery have the ability to schedule a repeat?**

- Yes: lottery can be repeating, and that is configurable. Not very granular, but good enough for "monthly lottery".

- **Can the price per ticket be adjusted dynamically: what is a reasonable price for a lottery including council nomination, validators election and democracy vote as valid calls? Can we adjust this taken into account token price volatility?**

- Price can be adjusted whenever a new lottery starts, but only at that granularity. For now, something like 0.1 KSM. This would not be dynamic enough to take in price volatility: We would need to wait until the next lottery and adjust the price again. We do not have an oracle for price at the moment.

- **If more calls need to be added as `validCalls`, do we need to start a new lottery or can this be added to an ongoing one?**

- New calls can be added dynamically if we use storage to do the call validation. If we want to do more fancy stuff like make it so that only democracy votes of a certain value qualify to participate for example, this would involve a runtime config and would require a runtime upgrade to modify the calls.

- **What is the reasoning behind using a delay at the end of the lottery?**

- Delay at the end of the lottery allows the design to be more resistant to the random number generation by a malicious actor. It may not be necessary in the short term, but it is good to have.

- **How does the pot work? Is it similar to the Society pallet? Does it have its own address?**

- Yes: it has its own address and works like the two treasuries currently on Kusama and Polkadot networks. 

- **Do we need a tab on Apps to show ongoing lotteries and statuses? Does the pallet allow only one lottery per period? Is the period 28 days on polkadot and 7 on Kusama (`spendingPeriod`)?**

- Yes: only 1 lottery per period is allowed. Some basic work to the Apps UI would be needed, for example making it easy to buy a ticket. You can configure how long the lottery is when opening it.

- **When a user calls a valid call: should a button be added on the 'Authorize Transaction' window to allow a user to purchase a ticket? If not, how do we envision a user purchasing a ticket without using the extrinsics tab?**

- Yes, that is generally what we envision, adding an extra "buy ticket" button on the extrinsic approval screen. 

- **`managerOrigin` (in charge of opening new lotteries) is not yet defined in the pallet: which collective will be in charge of opening new lotteries?** 

- Initially, the Council should manage this - this can be modified with a runtime upgrade. 

______________________________________________________________________________________


Full document can be found [here](https://docs.google.com/document/d/1sfvyTtTG43YO3bTGRveY-enWiiVsn61gFNhr9Yr89R4/edit?usp=sharing). Please leave your questions and comments!

Final Review: Lottery Pallet in Kusama Network

**Proponent:** RTTI-5220 (GLVeryFRbg5hEKvQZcAnLvXZEXhiYaBjzSDwrXBXrfPF7wj)

**Date: **January 2021

**Requested allocation:** 1530,00 USD / 18.43 KSM

**Proposed Curator Reward:** 2% of total - USD 30,00 / 0.37 KSM.

**Short description:** The idea of a sub-bounties extension aims to give more flexibility in the use of the pallet for curators to reward completed tasks without closing the parent bounty. This will contribute to achieve one of the ultimate goals of the pallet: to budget the networks' treasuries allowing bounties to extend their life cycles.
______________________________________________________________________________________


## **Context Of The Bounty & Problem**

In its current implementation, the bounty pallet allowed us to experiment with delegating the Council's responsibilities to a curator, defined as an expert in the topic the bounty touches. You can find more information about the current implementation [here](https://polkadot.network/kusama-and-polkadot-now-reward-curators-helping-to-scale-councils-functions-join-the-force-moving-the-community-forward/). 

However, the pallet does not allow the creation of **sub-bounties** by the curator (the address with agency over the funds of active bounties): if a bounty includes in its scope of work an N number of tasks, the payout to the implementers can only be executed once all tasks have been completed by awarding the bounty and closing it. This restricts the use of the pallet to small-sized bounties for a short amount of time.

The idea of a sub-bounties extension aims to give more flexibility in the use of the pallet for curators to reward completed tasks **without closing the parent bounty**. This will contribute to achieve one of the ultimate goals of the pallet: to budget the networks' treasuries allowing bounties to extend their life cycles. Other goals of this extension include:

1. To minimize tracking & execution management overhead to council members & improve governance efficiency.
2. To allow tracking & granularity in high budget allocated funds.
3. To allow iterations by starting a big proposal with a minimal viable fund and top-up based on progress if needed.

In the model we envision, a sub-bounty can only be opened using funds from an **active** bounty. This model allows the curator to allocate a specific amount of funds from the active bounty to a sub-bounty, and reward the task after completion by calling `award_subBounty`. After the call is confirmed, the sub-bounty is closed and the specific amount of it is deducted from the total allocation from the bounty (that stays open).

For a detailed description of the extension specification, budget and tasks included in the bounty, please visit the full proposal [**HERE**](https://docs.google.com/document/d/1_rsY5rSG5vkQJRIHSYB3161MMFreYKk00gKygY_L8QU/edit?usp=sharing). 

## **Notes**

Although the Kusama Council has the responsibility of deciding on the curator who will take the role if this bounty proposal is approved, we would like to suggest Bryan Chen (the original implementer of the bounty pallet) to review and evaluate the tasks' completion; this is the main reason why this extension proposal is submitted for discussion as a bounty proposal: Bryan has shown expertise in all necessary topics related to the bounty in order to develop this role. 

You can find the current implementation, along with the original ideas and discussions by the community in the links below:

- Original idea - [here](https://github.com/paritytech/substrate/issues/5713)
- Current implementation - [here](https://github.com/paritytech/substrate/tree/master/frame/bounties)
- Community discussion - [here](https://kusama.polkassembly.io/post/86)
- Bounties implementation spending parameters - [here](https://kusama.polkassembly.io/post/151)
- Final review on current implementation by the community - [here](https://kusama.polkassembly.io/post/237)

### Proposed Sub-bounty API & Signature

- Sub-bounties Extension: design discussion notes #7959 - [here](https://github.com/paritytech/substrate/discussions/7959)


Bounty Proposal: Sub-Bounties Extension Implementation 

After reaching the **900 validators milestone on Kusama**, we are reviewing network metrics to decide on further steps.

The full report can be found [**HERE**](https://docs.google.com/document/d/1VZYgy4tQtcjOU5xXOcMGLeSJ3QnaStaDjSbUgCZOAlY/edit?usp=sharing).

Recommended steps:

- The general recommendation of the team is **to pause any increase of validators from now on** in preparation for parachain deployment: BABE and GRANDPA are running smoothly, **but the parachains consensus logic is far heavier and more complex and will need optimization to reach that point**. As such, the parachains team is planning to only use some limited subset of the validators initially (perhaps 50, 100, or 200) randomly selected each session for parachain consensus. Those selected validators to do parachain consensus will receive the bulk of the rewards for each session. Over time, the amount of rewards each validator receives will be roughly equal, **but increasing the validator count relative to the amount of validators participating in parachains will lead to increased variance of rewards**. For this reason, the parachains team recommends keeping the amount of validators low to achieve an outcome of low reward variance, an earlier launch of parachains and consensus stability.

- Closely monitor the `MinStake/AvgStaked` ratio for network security reasons.


Performance Report IV: End of Motion 238 (Referendum 93), Increasing validators slots by 1 per 200 eras - 900 validators milestone

The goal of restructuring the voting mechanism in Council aims to increase the Council members' participation in all motions submitted to the collective.

The idea resumes in having 20 people selected to fill 14 council seats, and per motion / period, a random set of 14 of the 20 are picked to act as council members for that time. This will bring diversity to the decision making process and allow potentially lesser represented voices to be heard - the non-selected ones can also vote on the motions, but the selected ones will be the ones "punished" if they don't cast their vote. 

You can find the first initial approach [**here**](https://docs.google.com/document/d/129Fr_c4U7vxuansv6JGfE__xsjxlhhY1llbTiXVR7ps/edit?usp=sharing): please leave your comments and questions!

Council Vote Restructuring - An Initial Approach

A first testbed for a technical reviews bounty, aiming to complete the circle of on-chain proposal submission on Kusama and Polkadot Networks, by rewarding external developers who review deliverables of a funded proposal.

We have now, after some changes to the process, a more consolidated way of drafting and submitting treasury proposals for discussion, vote and deliver reports: but we find it difficult for Council members to fulfil a particular task: **to review the quality of the deliverables in a funded project**. The reason for this might be lack of time, expertise or both - we cannot expect all councillors to be experts in all topics a proposal touches.

We want to propose a bounty that will allow external technical users to review specific deliverables and be rewarded for it, supporting the work of the Council. 

Full link of the proposal can be found [HERE](https://docs.google.com/document/d/1awD1bv0XXyQnOKKEns7JvC2dL6TyV_ZCVtI_pmZX9jM/edit?usp=sharing): Please leave any comments, questions and concerns!


Technical reviews by Kusama/Polkadot Developers

As we experience a continued growth in the Kusama ecosystem, it becomes imperative to find ways to communicate with stakeholders in an efficient manner, making sure all information is distributed for informed decisions to be taken, especially in the case of Council and Technical Committee members. 

The goal of this proposal is to develop a **basic app that listens to on-chain calls and notifies Council members when their review and vote is needed**. An app to help councillors know once they are needed to push forward emergency mechanisms on-chain as well as other proposals would help mitigate the risk in the network. The app:

- would connect to rpc node;
- would connect with different networks;
- would notify about events;
- would watch wallet accounts and tell the user when pending;
- would have different alert levels;
- would recognise a "batcall" remark from council or TC members, with a `system.remark` "alertCouncil" that would trigger an alarm.

This proposal is submitted for discussion as a bounty and should be understood within efforts to increase council participation on the overall governance process and increase transparency in the governance process. The full bounty proposal, including tasks, budget and roadmap can be found [HERE](https://docs.google.com/document/d/1zsYYWWvbOXRZjez_N3lRl8memBEbhfTIj3JUP-CvAZQ/edit?usp=sharing).

Leave your comments and questions on the post! I would already like to suggest Mario (Polkastats) as curator and Ana (La Colmena - Bitcoinera) as implementer, but is up for Council to decide. They both have been crucial in the development of this proposal. 

Bounty Proposal: Kusama Council Alert App

Thank you to all council members for their participation and the feedback on the proposal, and to the Interlay team for the presentation and answering questions! As a short debrief, Let’s point out the main concerns of the Council regarding the overall proposal. The Council main reservations are related to:

1. **Competing liquidity pools between Kusama and Polkadot** and competition between similar tokens if the project gets access to two common good slots: one on each network. Some Council members stated that as independent networks but working to a higher end, Polkadot seems to be the right place for this project.
2. **Differentiation between networks**, protecting the Kusama community and allowing them to experiment in their own way. 
3. **Using limited resources** (in this case, common-good slots) in the most **efficient** way possible: allowing a fair distribution in the overall ecosystem. 

The Interlay team addressed these concerns with a proposal focusing on what they called “**InterBTC**”: one BTC Bridge for the overall ecosystem, starting on Kusama Network and migrating later (upon decision of the governance mechanisms) to Polkadot. 

The team addressed the 4 main questions they are looking to answer from the Council in this respect: 

1. Common good slot on Kusama, taking into account the Polkadot Council signalled in favour of this on Polkadot Network
2. Maintenance coverage by the Kusama Treasury
3. Bootstrapping and subsidies for relayers and vaults from the treasury
4. Governance design and ideas on a separate council, including composition and decision-making mechanisms


After the presentation, Councillors focused their questions mainly on the possibility of a **migration** (from Kusama to Polkadot) and the additional uncertainty regarding this, the risk of introducing the project on Kusama and the effects this might have for the community, and the potential inefficiency in requesting a common good slot in both chains (the concern of “limited resources”) by one project. Below, some comments from Councillors and community members to take into account:

- “To us (Polkascan Foundation) a common good slot and treasury funded subsidies for PolkaBTC on Polkadot makes sense (…) There is an ongoing discussion in & between the Polkadot & Kusama communities regarding the relationship between the two networks. It is our (Polkascan Foundation's) opinion that Kusama and Polkadot share a similar goal, which is the success of Polkadot. In our opinion Kusama exists to serve the goals of Polkadot and Kusama is taking relatively higher risk so Polkadot won't have to. To us this is a clear division of labor between the two networks and this creates a symbiotic relationship.  So the choice at hand for the Kusama Council is really a strategic choice which requires close coordination with the Polkadot Council. I'd like to echo Joe's concerns regarding the timeline and addition risk and complexity of a Kusama deployment and migration.”
- “One argument I heard for the 'rushed' deployment on Kusama, is a worry about competitiveness between the PolkaBTC Common Good chain and other BTC-Bridge competitors getting traction on the commercial parachain slots then that could be managed/mitigated by higher subsidies perhaps. Perhaps the Polkadot Council could double down on the commitment to support your project through the package deal. There will not be more than one BTC Bridge in a common good parachain. A common good chain would be able to compete with commercial competitors based on simple economics.”
- “Launching on Kusama seems to offer a huge amount of additional uncertainty regarding an eventual migration from Kusama to Polkadot. I feels somewhat rushed to launch on Kusama first. Why not simply wait for a common good slot and subsidies on Polkadot”
- “I don't want to discourage an entire class of application on Kusama - and I do agree that the public good slot and subsidy being a package deal makes sense - I just don't know if it makes sense in the context of multiple potential experiments to subsidize one specific experiment. But I do commend that treasury funding could mean you do not have to invent an additional new token to incentivize this”
- “Kusama feels like AIM and PolkaDot like FTSE100 as an ecosystem. Both are vital and both require deploying to both networks. I may be wrong but Kusama with current parachain auction schedule may have a number of parachains/parathreads/Dapps by the end of the year while PolkaDot maybe only have half a dozen but of institutional size If not deploying on both Kusama and PolkaDot how smooth this experience will be for Defi/Dapps hosted on Kusama with different blockchain specs (block time etc) between Kusama and PolkaDot?”

More questions and comments were made during the conversation, most of them were replicated in the live discussion and can be reviewed on the video. 

- Link to the video: [HERE](https://drive.google.com/file/d/1dGoX6aKT8HBjrTew358OhCus2yclSuUZ/view?usp=sharing)
- Link to Interlay’s slides: [HERE](https://docs.google.com/presentation/d/1VGzswYUbpFqSbdm8kgHeEG3_tHzz_j5HOXlQq0HIAOk/edit?usp=sharing)

This post is open for all council members and the community to leave your feedback and questions, to keep working on this proposal: let’s take this as a first step to make amendments to the proposal looking at Council’s and community concerns, thinking about the symbiotic relationship between Kusama and Polkadot.

Debrief on Kusama First Town hall Call: discussing BTC bridge deployment on Kusama Network

The Parachains Team has published [their report on network performance](https://polkadot.network/network-stability-report-kusama-with-parachains/) after the completion of the first 5 auctions. The report focuses on **4 key areas**:

1. **Candidate Production Stability**: The effect of network noise is not worth considering at this time, as over these past days the parachains have not had enough time to be repeatedly exposed to every possible combination of backing validators. There seems to be a discrepancy between some parachains related to this metric:To solve the issues mentioned in this point of the report there is a short and a long-time solution to be implemented (more info on [the report](https://polkadot.network/network-stability-report-kusama-with-parachains/)).
2. **Approval Voting Stats**: approval voting protocol is responsible for providing most of the security of parachains. Some incidents were registered, with a failsafe at 50 blocks which is being hit very occasionally, once every few weeks. These finality stall incidents are being investigated at the moment and the team will soon propose a solution to governance.
3. **Network Connectivity**: On Kusama, there are 900 validators, and every session 200 of them are randomly selected to participate in parachain consensus. Some validators seem to be over-connected (connected to most of the other 899 validators on the validation peer-set): This poses no problem for correctness but does present an opportunity for efficiency, while some validators are under-connected. Despite this, none of the validators have fewer than 100 connections, and therefore information should be gossiped to the validators.
4. **Load**: Most validators are in the 1.5-2 core utilization band. The team’s current recommendation is for validators to run with 4 core CPUs, so CPU utilization is within expectation.

Overall, the network is running smoothly. Parachain block production, approvals, and finality are stable with occasional incidents relating to temporary stalls of block finalization: These stalls are being caught by a failsafe and thus were not detrimental, but the underlying cause is being investigated and a solution to remedy this will be proposed. These results seem to suggest that there are no roadblocks to further parachains being added to Kusama Network.

The link to the full report can be found [HERE](https://polkadot.network/network-stability-report-kusama-with-parachains/). You can leave your questions and comments here or in the [Direction channel](https://matrix.to/#/!QXMnIJzxlnVrvRzhUA:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=corepaper.org).

Network Stability Report: Kusama With Parachains

Adding a more extensive explanation for the tip below.

Hash: 0x250d7d52b1e6533bb330b0bdbcc8eb5e293b2f28c42b68642e74455d23b8b3cc

Registrar #1 has continuously worked on ways to improve the identity verification process, the difference is remarkable from my first verification. Given the relevance of the Registrar Verification Request for current governance issues and the potentiality of its usage in the future, this should not pass unnoticed. 

Still, he mentioned he has a lot of work to be done in the background to:
- achieve more checks
- be faster
- create a more seamless user experience

Registrar #1 is continuously working to enhance the experience, including email notification, new checks and tools to create a semiautomatic verification process.




Tip for improving the Registrar Verification Request process for Registrar #1

Let's go back to the past discussion on how to use the Treasury effectively. 

Treasury-pallet Bounty Extension #5713 (https://github.com/paritytech/substrate/issues/5713) tries to tackle the issue with spending instruments. At the moment, the Council has two distinct Spending Instruments at its disposal to execute payouts from the Treasury but these do not scale and council members do not have time, expertise or interest in activating the mechanism. 

In order for a Council to be successful, it should have a general direction and thus have (strategic) objectives. At the very least a Council should work from a coherent set of core-values. When a Council puts its Treasury's funds to work to achieve those objectives, execution of that work should be effective (and ideally efficient). 

Extension #5713 proposal **offers an initial option for "budgeting" the Treasury funds**, at least in a more ad-hoc way for now. Thanks to previous discussions we can summarise some open questions on the design:

1. A `BountyActivated` bounty should be cancellable by the council? Yes / No. 
2. Should Time to Deliver be set up on the design? this would allow avoiding with the problem of a "sleepy"curator - Yes/No.
3. It should be a best-practice by the Council to only approve Curators that can be held accountable: how to avoid "bad"curators or lost of access to address?

3.a. should the curator be a Multisig? Yes/No.

3.b. should a curator have a verified identity? Yes/No.

3.c. should a curator be part of the council? Yes/No.

3.d. should the council be able to change curators? Yes/No.

3.e. the idea of *sub-bounties*: should curators have the capacity to create sub-bounties? Yes/No.


**Please keep in mind the goal is to solve scalability with regards to Treasury spending**. With a clearer agreement on these topics we will be able to move this experiment further, maybe add new elements and start using these funds for Kusama's benefit. 

Please add your answers to the questions above and any other point I am missing for this discussion, I am sure there are more open questions and these are only a few. 

Current implementation : https://github.com/paritytech/substrate/pull/5715






Reopening the discussion on Bounties and Treasury spending issues! Open questions

Hash: 0xc694d6dfd35dc09bb9ea30c607305d71d011f48a9485c0131cccc784892cc4a6

Tip proposal for preparing and publishing the blockchain-comparison.com page on Polkadot and Kusama, including comparable variables with other projects such as use cases, community and comms, wallets, history of the project, non-technical resources, tokenomics, governance, and more. 

Visit the page here: https://blockchain-comparison.com/project/polkadot/

It is also possible to add new information. 