Extrinsics.io is an extrinsics building platform that provides an improved user interface and experience for users in the Polkadot and Kusama ecosystem. It has a fresh new take on building and signing extrinsics that enables both regular users and power users to better understand and utilise the extrinsic builder. It will also provide users of the currently available wallets with tools that help make calls to the network that are not currently available in any of those wallets.

![](https://i.imgur.com/AhQwWGr.png)

Our goal with extrinsics.io is to build a platform that makes it easier for new users to understand and utilise the extrinsic builder with more comfort and ease while also making sure that power users can quickly get to what they are looking for when they have to build an extrinsic. Here are some key points that highlight those changes:

- Unified screen for encoding and decoding extrinsics

- Intuitive Decoder View

- An editable decoder UI

- A better interface for the encoder

You can take a look at the full proposal [here](https://docs.google.com/document/d/1Ty52DlBTx9Lf14vzYnIaIBoRC2kaRCU3EG9B_KRZd3E/edit?usp=sharing)

The platform would also support signing of extrinsics functions with both Kusama and Polkadot. We would start with supporting both Kusama and Polkadot networks with the option of extending it to other networks at a later stage.

The proposal consists of just one milestone and an estimated 3 months to complete. After Milestone 0 is completed we plan to make a report that will be shared on Polkassembly and Kusama Direction.


We would love to hear your feedback and get your thoughts around the project. Feel free to leave a comment below, or reach out via email, anytime.

- This submission covers the expenses for the entire proposal.
- Kusama rate at $206.654 as per [Subscan 30 day EMA](https://kusama.subscan.io/tools/charts?type=price)

[Link to the recent discussion on Polkassembly](https://kusama.polkassembly.io/post/1328)

Extrinsics.io - An improved extrinsics builder for Polkadot and Kusama

Hello !

Here is my proposal for a analytical website to help members of the DOTSAMA community to view data points on their wallets. These data points include Total Fees Paid, Source of funds, Wallet worth, Charts of spending, Total Deposits, Total Withdrawals, Paper handed funds, Diamond handed funds, Monthly stats and more !

Here is the [link ](https://docs.google.com/document/d/1LzoLLbo91wn_xs581MQLGOguAcm7PFVVPngoSUT0FEo/edit?usp=sharing)for the full proposal on Google Docs

Requested KSM using EMA30 = 85.084 KSM ($17,585.00 requested / $206.679 KSM average)

Let me know any feedback or ideas you have I would be very happy to hear them!

Many Thanks, Lorimer

[Twitter ](https://twitter.com/lorimer_jenkins)[Linkedin ](https://www.linkedin.com/in/lorimerjenkins/)[Email](mailto:lorimerjenkins1@gmail.com)

My Wallet Treasury Proposal

Hi I’m Jay Chrawnna and I’ve been writing and producing educational, cultural, and news digest videos for the Dotsama community since June 11, 2021 — Now 102 videos across 5 series. Cumulatively this equates to 57,687 views and 3118 watch hours.

The following proposal seeks funding for the ongoing production and development of SER, Have ya’ Heard? (formally Slot Election Reflection) - A week-daily broadcast covering Dotsama news, culture, interviews, tutorials, and trends all with sources displayed on screen and linked in the description.

Funds will cover existing production costs, new marketing initiatives, further development, and expanded community involvement.

See the full proposal [here](https://docs.google.com/document/d/1A_JZsQj-Jgx1XNPkzvivOaP9kjQ4byV4i-6069gq9Ow/edit?usp=sharing).

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

Further community feedback may be found on this [tweet](https://twitter.com/GldnCalf/status/1484181410105769984?s=20).

All our welcome to leave feedback below!

Proposal for funding production of the week-daily SER, Have ya’ Heard? Community News Digest

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.

Subsocial parachain recovery 

Expedite Proposal #53

This is a bounty proposal whose proposer address (DdtBope22Y8q53iPNBj5wGVaRzrSKHrZA4bGSWJHCxe8bmL) 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.

remove stale bounty proposal

This is a bounty proposal whose proposer address (HjnsZobSwPXDgHLpCm7uBHX3AvqFSVsFs3jqM38FRp3jv6z) 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.

closeBounty - no information about the proposal

Since 377 was scheduled erroneously with a threshold of 10 voters, motion 380, which attempted to cancel it with a threshold of 13 voters, failed (the origin of 10 voters != the origin of 13 voters, unfortunately).

This motion must also be executed prior to 381, but only requires a threshold of 10 voters.

Cancel currently scheduled flawed agenda (380 amended)

This motion is #379, with the erroneous tabs and cancellations removed - PLEASE VOTE FOR #380 AS WELL if you vote for this, thanks. Edit: Please vote for #382 prior to passing this - if you are the closing vote, please make sure #382 has already passed before closing!

still no changes to the originally proposed schedule.

No Tabs, Bad Thresholds, or Excessively Long Auctions Guaranteed!

[previous motion](https://kusama.polkassembly.io/motion/378) was proposed with an incorrect threshold - fixed now. 

order of cancellation and rescheduling calls have been altered to avoid duplicate proposal - semantically the proposal is identical.

Duration Fix + Threshold Fix

EDIT: incorrect threshold - this will do nothing

~~Cancel and reschedule the scheduled lease period auctions with all parameters exactly the same, other than `duration` (of the auction)

My error was that I was specifying the ending period for `duration`, when `duration` specifies the starting period - I had specified 72000 (5 days), but the ending period is already hardcoded to 5 days onchain - I am now specifying 27000 (45 hours [2 days - 3 hours for randomness]) as should have been specified in the original motion.

Sorry for the any confusion!

To any readers: nothing has changed in what you should expect - the previous motion had an error which this motion amends.~~

Duration Fix

this motion schedules auctions (during lease periods 16->23 inclusive) for 8 [edited from 7] lease periods (17->24 inclusive) 

as per the parameters described [here](https://kusama.polkassembly.io/post/1010#f37ee023-26e0-4808-8ea9-e9a6879f3c6a)

I've opted to propose auctions for the lease period AFTER the auctions run. 

auctions for 8 continuous lease periods

As per the discussion in Kusama Direction today, I am proposing a motion for majority referendum to *schedule* a new auction immediately after the end of the current auction. 

Parameters for the scheduled call can be seen in the submitted preimage - block 9534968 is exactly `5 * DAYS` after the beginning of the end period of the current auction - other parameters are taken from prior auctions (starting period of `27000` blocks, current lease period `15`) 

edit: please vote NAY to this motion, `5 * DAYS` is insufficient time on it's own to close the auction after ending period begins. 



Proposing a referedum to schedule the 6th auction for lease period 15

This is a bounty proposal whose proposer address (Di6FRNeGYi9GvLVko8H7yVrcXXvdd6Bn6dLFEQ9pkfCqFga) 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.

Cleaning up erroneous(?) bounty 

Cyberfuture on Parachains by bitfwd 比特未来: 15th + 22nd April 
Name of the event: Cyberfuture on Parachains

Medium post: 
https://medium.com/bitfwd/cyber-future-on-parachains-virtual-event-5f5bac3e78d5

Schedule: 15 & 22 April 2021
Format: Online event 
Submitting: on behalf of Bitfwd 比特未来 (bitfwd.com)

We are  preparing  the "Cyber future on Parachains" online event. We decided to organise this event to educate the community and share the latest development on Polkadot.
The event will be run in two parts, 1 per week spread across two consecutive weeks. 
Leading up to the event we are intending to produce engaging content to be spread across social media.
1st session:
DeFi use cases and developer focused component
The first session will be focused on Polkadot introduction:
General overview and introduction to Acala - a DeFi parachain on Polkadot. This session will aim for introduction into the Polkadot ecosystem for newcomers and beginners and encourage them to get involved as a developer on Polkadot and Kusama, DeFi on Polkadot and data querying on Polkadot and Kusama.
2nd Session
Culture, ecosystem building and crypto entrepreneurship in the polkadot ecosystem.
The event will be focused on Art on Kusama and Polkadot with speakers that are working on NFT protocols and standards for the Kusama network. This session will aim for Polkadot art in general, NFT minting on Kusama and how it works, on chain standard for custom notes on Kusama protocol (RMRK). We will also share in this session the fascinating business case of how Polkadot became a phenomenal case study of how to grow the global open source ecosystem harnessing the Chinese developer ecosystem that is spread across the world. 
Proposed Speakers:

Our aim is to create content before the event (announcement) and educational content after the event in video and written format.

Our Ask:
10k USD in KSM for operation costs:
Event planning
Content creation before and after the event (video, blogs, visual banners)
Promotions in communities

About bitfwd 比特未来:
Bitfwd 比特未来 (bitfwd.com) is an open source grassroots crypto community that started in Australia since 2015, we’ve been facilitating collaborations between academics, entrepreneurs, advisory to governments (in Australia and New Zealand) and supported numerous startups, including some of the hottest up and coming projects in the Substrate ecosystem: SubQuery, DeepDAO) . We are a 
Our team is experienced in running events managers, producing content and we are very excited about the developments in the writers that would love to host virtual events about the Polkadot ecosystem as we’ve been following closely since 2017.
Track record Since 2015:
Earlier this year we have facilitated a 3 event series about DeFi and DAOs and hosted
Multiple Blockchain hackathons in China and Australia universities (example: https://youtu.be/eHsdvfZ4QOU)
Numerous Meetup events: https://www.meetup.com/en-AU/bitfwd/
Government advisory: Australian treasury (FED equivalent) and National blockchain Roadmap, Blockchain New Zealand (national tech industry representative body) 


Proposal details on the following link:
https://docs.google.com/document/d/12313XU9ksKHah4M5vTXlRFFo1gag-FP5PV1jCtwh6TQ/edit?usp=sharing

This is a treasury proposal whose proposer address (HqodK73hLWCZ1EzpdFdeyCEJnTsRBezTPZxPJqX3nHkc765) 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.

Cyberfuture on Parachains by bitfwd 比特未来: 15th + 22nd April 

**DeepDAO** is a discovery platform for DAOs and governance systems, centered on analytics and information gathering. Our main dashboard enumerates and ranks DAOs using several key metrics such as membership and assets under management (AUM). We are constantly expanding both coverage of DAOs and the metrics that quantify and measure the dynamics of governance processes in DAOs.

DeepDAO currently reports both financial and governance data on 100+ Top DAOs across five major platforms - Aragon, Moloch, DAOstack, OpenLaw and Colony. All DAOs on our system currently run on Ethereum or xDAI, and we are expanding our coverage to other chains and governance platforms as well. DeepDAO data is being used by major research firms (Delphi Digital, Messari), journalists, VCs, and DAOists across the ecosystem.

**The end goal of this proposal** is to list the Kusama Network (and in the future other Substrate organizations) on web-based platforms that collect data for users (like https://deepdao.io). The Kusama Network will work as a first experimentation approach when deciding how to organise the data collected, and will allow us to understand the mechanisms better.

Kusama would be listed together with all the other DAOs on DeepDAO, and potentially other platforms and ranked according to several metrics. Special sections are dedicated to each DAO on these platforms, and include related links, social media, written material, and data aggregation and analysis.

[Link to the full text of the proposal](https://docs.google.com/document/d/1bghiKUiGg47wt2glzzEGxGBy1eYHsCsQWPbhj-NH34U/edit#).

Proposal DeepDAO <> Kusama Integration

prior discussion on COSMOON slash: https://kusama.polkassembly.io/post/490

it's my opinion that ParityDb should already be understood to be experimental, but it's prevalence in communications and use in public benchmark statistics leads me to believe that there are likely significant numbers of independent validators using it in production already.

Since this slashing event has caused a revision in CLI flag names and explicit recommendations, it is probably reasonable to continue as if prior to this event the risk was not well-enough understood. 

I am putting forward a motion to cancel the slash of COSMOON based on that assumption. 

slash forgiveness for era 1898

**Short Description**: This project will extend [KodaDot](https://kodadot.js.org/) (rewrite original [PolkadotJS](https://polkadot.js.org/apps/) in [VueJS](https://vuejs.org/)) with an NFT explorer. The NFT explorer main idea is to incorporate the workflow of exploring, issuing, querying and sending NFTs between users. Our idea is wrapped around the possibility and accessibility, to easily create a marketplace for anyone who is non-technically savvy to be able to use it from a mobile device.

**[Original proposal document](https://docs.google.com/document/d/17hN0Xakc5ie-GlPRBydUSSrXFngo_6fg-LT9EcVmgao/edit?usp=sharing)**

## 
**1. Context of the proposal**

The goal of this project is to create a universal NFT explorer and marketplace interface later for non-fungible tokens on Kusama. With the final outcome of this proposal, users will be able to mint, transfer, and burn NFTs on the network. On top of this, transfer functionality will be extended with buy and sell features, which will be later translated into a marketplace. We are looking to filter options for galleries to be curated and anyone to participate.

Our primary deliverable will be an extension of KodaDot: an NFT explorer as open source library for future NFT pallets operators to use.

The team would like to embrace various properties of ownership and rental manipulation for various use-cases, not just art. ERC-1155 (i.e batch operations of ERC-20 and ERC-721), ERC-1633 (timeshares, co-ownership, fractional ownership), ERC994 (delegation), ERC-998(composable NFT), ERC-809(renting), ERC-1201(tokenize ownership and rental rights) and in future cover this integrations in our NFT explorer.

## 
**2. Problem statement**

[Unique Network](https://github.com/usetech-llc/) or [RMRK.app](http://rmrk.app/) proposed solutions to mint NFTs, however, there is little to no UX right now to mint, transfer, filter, list and trade NFTs inside the original interface.

Although a PoC gallery is being developed as part of the [NFT Strategy for Kusama, ](https://docs.google.com/document/d/1hflIRKG207uuWkE13lZbFBaf6f4qF_3uvsctNoZFH0o/) having a user-friendly interface will allow a simpler onboarding process for non-tech savvy users into the world of non-fungible assets.


## 
**3. Functional objectives**

*   User is able to view, manage and operate non-fungible assets;
*   Create components allowing upcoming Substrate pallet provider to easily adopt KodaDOT: NFT Explorer;
*   Users would be able to explore and interact with assets in AR/VR world
*   Future-compatible open-source library front-end library.
*   Attract new user base to Kusama ecosystem through AR/VR functionality [[1]](https://twitter.com/FeiStrife/status/1335404817821339656)
*   Experiment over new usages of NFTs applications, i.e. bundle scene as NFT

## 
**6. The team behind it**

*   Matej Nemcek ([@yangwao](https://twitter.com/yangwao)) - Co-Founder of [KodaDot](https://twitter.com/kodadot), VueJS background, more info [hypersignal.xyz](https://hypersignal.xyz/)
*   Viktor Valastin ([@vikiival](https://twitter.com/vikiival)) - Co-Founder of [KodaDot](https://github.com/vue-polkadot), [Publication about carsharing dApp on ETH](https://www.researchgate.net/publication/335241161_Blockchain_Based_Car-Sharing_Platform) using ERC721 token composition. Working for a company which is creating car-management software(React, Spring) and R&D in blockchain.

### 
**Team Code Repos**

*   [github.com/yangwao](https://github.com/yangwao)
*   [github.com/vikiival](https://github.com/vikiival/)
*   [github.com/vue-polkadot/apps](https://github.com/vue-polkadot/apps)

### 
**Team LinkedIn Profiles**

*   [linkedin.com/in/mnemcek](https://linkedin.com/in/mnemcek)
*   [linkedin.com/in/vikival/](https://www.linkedin.com/in/vikival/)

## Work being already done towards this proposal

* [We’ve done a prototype on top of Usetech Substrapunks](https://twitter.com/KodaDot/status/1327969683992145924)
* [prototype RMRK reader on top of RMRK specification](https://twitter.com/KodaDot/status/1331657696508932097) 
* [Our recent hacks AR NFT's using RMRK reader on top of Kusama](https://twitter.com/KodaDot/status/1334902453440024578), and [it seems to have good vibes](https://twitter.com/KodaDot/status/1334902453440024578/retweets/with_comments)
* [Part of M1 being done ahead of time](https://twitter.com/KodaDot/status/1348591070993653761)   




KodaDot NFT explorer

After many requests by users to integrate Kusama Network to [**Rotki**](https://rotki.com/), the Rotki team aims to integrate with 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. This submission cover milestone 1!

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.

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

Milestone 1 - Native Kusama support in Rotki

This is a treasury proposal whose proposer address (HbRDcDo1EuHmU7ZV4tot1hUCvmHNHbXbq1REvEg3cUKCM4c :

Following previous discussion [Here](https://kusama.polkassembly.io/post/313)

As part of the NFT strategy presented [here](https://docs.google.com/document/d/1hflIRKG207uuWkE13lZbFBaf6f4qF_3uvsctNoZFH0o)
Everdreamsoft aims to submit a proposal to the council to build a library for asset tokenization features (NFTs) on the top of Kusama network.

The objective is to simplify the workflow of issuing, querying and sending tokenized assets, commonly known in the blockchain world as NFTs. Within the scope of this proposal and (Milestone 1) we will create a visual NFT gallery where users will be able to view their collectibles, metadatas associated with tokens, in a visual manner. The tool will be provided open source so anyone will be able to create their own gallery.

PolkadotAssetJS is designed to be extendable to easily integrate new substrate asset pallets. In the scope of this project, PolkadotAssetJS plans to follow Kusama NFT development plan to constantly adapt to most relevant pallets or available technologies. The first milestone covers the RMRK protocol in order to deploy NFT capabilities as soon as possible. Future milestones will integrate new pallets and tools as they develop, such as ORML pallet, Unique, and smart contract based tokens.
But the compatibility might be adapted to the most relevant pallets depending on the level of maturity and adoption in Kusama.

Main delivery is a web application allowing to view Art and Collectibles available on a Kusama wallet in a visual manner. The app will be able to display NFT balances as well as NFT transaction history, using RMRK.app tokens. EverdreamSoft will issue some collectible images as an example and connect available collections.

Along with the web application EverdreamSoft will provide an open source library allowing any developer to display RMRK tokens and display their own NFT curated collections and balances.

The library is written in Typescript and uses PolkadotJS as a dependency. The library uses an abstract architecture for token definition allowing to easily implement new NFT pallets while keeping the same code workflow.

Read the full proposal here : [Google Doc](https://docs.google.com/document/d/1eNgiT9hVt8itBgr1mK57SzbyOgU7TMOPb-_0-XzIwQE/edit?usp=sharing)

**Deliverable**

Main delivery is a web application allowing to view Art and Collectibles available on a Kusama wallet in a visual manner. The app will be able to display NFT balances as well as NFT transaction history, using RMRK.app tokens. EverdreamSoft will issue some collectible images as an example and connect available collections.

Along with the web application EverdreamSoft will provide an open source library allowing any developer to display RMRK tokens and display their own NFT curated collections and balances.

The library is written in Typescript and uses PolkadotJS as a dependency. The library uses an abstract architecture for token definition allowing to easily implement new NFT pallets while keeping the same code workflow.


Basic library architecture a class diagram delivered

1: Blockchain abstract class with the abstract logic
With an implemented Kusama Blockchain class

2: Asset concrete class and flexible metadata logic
With an implemented RMRK Metadata Solver Class

3: TokenPath abstract class and abstract logic
With an implemented RMRK Token Class

4: TokenContract abstract class and abstract logic
With an implemented RMRK Contract Class (Natively called collection in RMRK app but defined as contract for a maximum compatibility with other potential pallets)

5: Pallet Package architecture to easily implement potential new pallets





PolkadotAssetJS an NFT interface for developers and artists

The funds applied for in this proposal will be used for the operating expenses of SUBSCAN (Kusama network) from** December 2020 to February 2021**.

https://kusama.subscan.io/

According to the October Google Cloud Platform bill from SUBSCAN, the cost to KUSAMA network is about $850. SUBSCAN have already borne the operation and maintenance costs for more than one year. Our project currently lacks sources of income, in order to continue to operate, we need to apply for financial support.

**Operation and maintenance costs include:**

Compute Engine

Cloud SQL

Stackdriver Logging

Cloud Storage

...

If a more detailed bill is required, we can provide it to council members privately. Please understand that this involves some trade secrets.

This time we did not include all the operation and maintenance costs in the proposal. We are willing to continue to afford part of the cost of these network and contribute to the ecology.

In the future, We are tentatively applying once every quarter. Or, at the beginning of each month, Apply for funding allocation based on last month's bill. We are looking for a sustainable business model. After earning income, we will gradually reduce the amount of application and become an independent ecological project.

The operating expenses of SUBSCAN (Kusama network)  from December 2020 to February 2021


This is the first milestone of "Robots Waiting for Kusama" proposal. 

The initial post is here: https://kusama.polkassembly.io/post/297. The detailed document is avaliable on [Google Docs](https://docs.google.com/document/d/1jnnlEmOayiFt3bAajsXa3a3qbAKEWbSA7P0Oup-NhmU).

The purpose of the proposal is to demonstrate current capabilities of Kusama network for robotics technicians working or studying at universities by presentation of already available web3 tools. A large-scale demonstration with colleagues from partner universities will be conducted for this, in which various robots will function, being integrated in a test environment using the Robonomics parachain. The proposal is divided into 5 milestones with 10 robotic devices each + the last milestone for final montage and summing up.

The first milestone includes:
- Negotiations with universities about robotic devices for demonstration (10 devices for this milestone).
- Coordination and technical support of participating university members.
- Preparation devices and the formation of deliverables.

For each robot the following will be done:
- analysis of the ROS-module of the device, correcting the module if necessary, testing the module;
- robot activation;
- collection and sending of telemetry data;
- preparation of results: creating video, documenting a repository, posting a report.

For the first milestone, we are asking for 850 KSM, which will be used to prepare robotic devices (80 KSM per 1 device) + 50 KSM for operational costs. The milestone will take approximately 12 weeks to complete.

This is a treasury proposal whose proposer address (HqnKDzYBnFpGH5jXYZmUFXFnz76ynKN6nTh3De3oRxA9gYu) 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.

Robots Waiting for Kusama: Milestone 1

This is a treasury proposal whose proposer address (DeFR1kGwiAYp1mqCpozD5h6ARZrrMgMykBCcJVPaLFYgSmk) 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.

This is a request for payment for WP1 delivery, as presented in 
### [this post](https://kusama.polkassembly.io/post/310)

Council Governed Wiki - WP1

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). 

Validator Resource Center and Ranking Website

 Approve a proposal. At a later time, the proposal will be allocated to the beneficiary
 and the original deposit will be returned.

 May only be called from `T::ApproveOrigin`.

 # <weight>
 - Complexity: O(1).
 - DbReads: `Proposals`, `Approvals`
 - DbWrite: `Approvals`
 # </weight>

Hi all,

I would like to open the discussion for a possible new recurring spending proposal: PolkaStats aims submit periodic spending proposals to the Kusama Treasury to fund hardware operational costs.

PolkaStats is a Substrate block explorer aiming to provide the best staking and economic data for both validators and nominators. It helps both types of users by providing comprehensive metrics, charts and utilities to improve their knowledge and performance.

PolkaStats is one of the projects that was born in La Colmena, a crypto community based in Sevilla, southern Spain. The community aims to incentivize content-creation in Spanish for Polkadot, Kusama and other blockchain projects and, as supporters of open source culture, develop software to contribute to the ecosystem. The organization also acts like an incubator that helped create blockchain business models like DragonStake or Delega Networks validators.

Although there are currently already some very good Substrate explorers in the ecosystem, PolkaStats has a different perspective to offer in order to increase diversity among the existing solutions. PolkaStats differentiates from other explorers in:

Focusing on Proof of Stake chains only.
Being a Javascript based block explorer (both frontend and backend)
Utilising Vue.js / Nuxt.js frameworks used in frontend, with a low learning curve.
Allowing Incipient wallet functionalities
You can find all details of the proposal (including a detailed monthly budget and roadmap for the next 7 months) here:

https://docs.google.com/document/d/1eJIyyyl2Asr8tX05zpO-sUOa2aSoeIlCGag030t0vrA/edit?usp=sharing

PolkaStats hardware operational costs treasury expense proposal

This is the 1st milestone of [Kusama darkpool proposal](https://kusama.polkassembly.io/post/142)
In this stage, we will built basic functionalities for AssetsHub which will stay in Kusama forever:
- Lock the native token, relay chain token (KSM), and parachain tokens
- User issued token for assets gateway
- Assets withdraw
- Transfer between the pallet and the trading engine
Will first implement the naive TEE-based version


M1-1: Private Assets

This is a treasury proposal whose proposer address (J9nD3s7zssCX7bion1xctAF6xcVexcpy2uwy4jTm9JL8yuK) 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.

Participation Lotteries on Kusama

This treasury proposal is for the fifth and final milestone of the - Non-Custodial P2P Trading for KSM proposal.

Details of the proposal can be found here: https://docs.google.com/document/d/1m_lBnw6zrkW980zkZhHEJ_Ny6eEUAJk9ey0GSmevleU/edit?usp=sharing

Milestone 1, 2, 3 and 4 have now been completed.

Commonwealth thread: https://commonwealth.im/kusama/proposal/discussion/415-treasury-proposal-noncustodial-p2p-trading-for-ksm

Original Riot announcement: https://riot.im/app/#/room/#kusama:matrix.parity.io/$Ud1f2HzQuTDV3tsTVu1bp2ozFQHcX0qo_vAPztPJB4w

**Milestone 1: Reference Implementation**

https://github.com/LocalCoinSwap/kusama-reference-implementation/blob/master/Kusama%20reference.ipynb

**Milestone 2: Python handler class and Python library**

Package source code: https://github.com/LocalCoinSwap/kusama-utils

Tests with 100% coverage of the library: https://github.com/LocalCoinSwap/kusama-utils/tree/master/tests

Documentation: https://localcoinswap.github.io/kusama-utils/

Official Python package in the PyPi library: https://pypi.org/project/ksmutils/

**Milestone 3: Kusama non-custodial API**

API: https://hub.docker.com/r/localcoinswap/kusama-api

Automated setup documentation: https://github.com/LocalCoinSwap/kusama-api/blob/master/docs/setup/2.-prod-deployment.md

**Milestone 4: Kusama exchange API:**
https://localcoinswap.com/api-docs/#


Questions or feedback is always welcomed.

We are excited to move on to this final milestone!

Non-Custodial P2P Trading for KSM - Milestone 5 (Final)

> This is a proposal to verify that M2 & M3 has been completed.  

#155 Polkawallet Treasury Proposal - Overall Application:
 [https://kusama.polkassembly.io/motion/155](https://kusama.polkassembly.io/motion/155)  

Overall proposal application document: [https://docs.google.com/document/d/1sl6VQDcCwhTqwy-5PlSSO31okJZmDLe7WiTnlj5ezJQ/edit?usp=sharing](https://docs.google.com/document/d/1sl6VQDcCwhTqwy-5PlSSO31okJZmDLe7WiTnlj5ezJQ/edit?usp=sharing)  

Project Github (Apache-2.0): [https://github.com/polkawallet-io/polkawallet-flutter ](https://github.com/polkawallet-io/polkawallet-flutter )  

Date of M2&3 proposal: 2020.08.14

**Milestone 2**  

> Governance (Expand existing functions)  

- A. Treasury  
   -  a. Display the basic parameters of the Treasury, including the total number of proposals, the number of approved, the total amount available, the launch period, etc.  
   - b. Display treasury proposals, approved, tips, and related information.  
   - c. Council members can vote on proposals.  
   - d. Council members can endorse the value of tips.  
   - e. Initiating the Treasury proposal.  
   - f. Submit tip request, report awesome.  

- B. Democracy  
   - a. To show the proposals, and info.  
   - b. The second operation can be performed on the proposal, which means that the user is interested in a proposal.  

- C. Council  
   - a. Show motions and be able to vote.  

Duration: 3 weeks,  Costs:  1929 KSM  


**Milestone 3**  

- A. Discussions  
   - a. Connect to the polkassembly backend ([https://github.com/paritytech/polkassembly](https://github.com/paritytech/polkassembly)）  
   - b. To receive and publish information about on-chain/off-chain discussions. （[https://kusama.polkassembly.io](https://kusama.polkassembly.io)）  
   - c. Log in to polkassembly directly with a wallet account.  

Duration: 3 weeks,  Costs:  1929 KSM  

**How to verify the work?**

1. Install App  
You can check the code: [https://github.com/polkawallet-io/polkawallet-flutter](https://github.com/polkawallet-io/polkawallet-flutter), or test it.  
Go to the official website to download the beta version: [https://polkawallet.io/#download](https://polkawallet.io/#download), available for Android and iOS.  
Now is the beta version, please backup the mnemonic words.  

- iPhone: Open [https://polkawallet.io/](https://polkawallet.io/) use iPhone Safari, go to download page, Click iOS DOWNLOAD. Version ≥ 0.9.1 (The last version is 0.9.3, fixed some issues)  
- Android: Open [https://polkawallet.io/](https://polkawallet.io/) use Android phone, go to download page, Click ANDROID DOWNLOAD . Version ≥ 0.9.1 (The last version is 0.9.3, fixed some issues)  

2. YouTube video:  
- M2 for governance: <https://youtu.be/UqVoljQ32xs>  
- M3 for Polkassembly: <https://youtu.be/vWoG-Uly2EI>  


**About appropriation**  

This proposal applies for kusama treasury funding. Initiating proposal and receiving address:
`EyWJe5kRSpDXLSaUxE3WcoDSgSos2TpRL2rSSd45R61YRqH`  
Identity: `POLKAWALLET`  

**Info about Polkawallet**  

Website: [https://polkawallet.io ](https://polkawallet.io )  
Twitter: [https://twitter.com/polkawallet ](https://twitter.com/polkawallet )  
E-mail: [hello@polkawallet.io ](hello@polkawallet.io )  
Riot: @0xthreebody:matrix.org   
Github: [https://github.com/polkawallet-io](https://github.com/polkawallet-io)


Polkawallet Treasury Proposal - M2&3

This is a treasury proposal whose proposer address (FaHid4XXVQLZpkBQ9sjqqDk9ef4ugrWRsSkRqnUMDXSN3PW) 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.

This is a motion whose proposer address (H9eSvWe34vQDJAWckeTHWSqSChRat8bgKHG39GC1fjvEm7y) 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.

We propose to develop a council-governed Wiki in Kusama capable of
storing content such as subjective agreements, guidelines for treasury management,
onboarding information, hashes, and links to official software releases, branding material,
and other important information. The Wiki can only be updated on-chain and by the
council.

The work to be done consists on integrating our existing technology for on-chain GIT-like content management within Kusama blockchain. 

The work will take 10 weeks of development and we have budgeted a cost of 17.5k USD. After this, the Wiki will be available to be used by the council and Kusama's community in general.

**This proposal corresponds to the first payment of 20% (3.5k USD at 7.5 USD/KSM) of the total amount** and it will cover the work until the first milestone is delivered. Two other payments, of 32% and 48%, are planed after that intermediate milestone and the final one are delivered, correspondingly. 

[You can read the full proposal here](https://drive.google.com/file/d/1p__nY_Y8rt7nKzQqhiAxYqoBKxpvzn91/view?usp=sharing)

This proposal was first shared as a discussion [here](https://kusama.polkassembly.io/post/166). Thanks to @JAM @Julien, @Raul, @Thibaut and @ThomIvy for their help and support.

*About us:*

I'm [Pepo](https://github.com/pepoospina), the co-founder of [The Underscore Protocol](https://www.uprtcl.io/), a protocol inspired in GIT, but adapted to work with ideas instead of code. 

Council-Governed GIT-like Wiki

This is a treasury proposal whose proposer address (DWUAQt9zcpnQt5dT48NwWbJuxQ78vKRK9PRkHDkGDn9TJ1j) 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.

This is our treasury proposal for the third milestone for LocalKSM.com.

Milestones reports can be found here:
Milestone 1: https://drive.google.com/open?id=174du6m0a2M5KDgFJuzd2cYkk33JZOTkg
Milestone 2: https://drive.google.com/file/d/1eIa1dYsI35xYZ2s78Aqfk1ToLSq967_f/view

Code for M1 and M2 deliverables:
LocalKSM github: ​https://github.com/localksm
App code: h​ttps://github.com/localksm/app
AP Kusama integration: h​ttps://github.com/localksm/nitrogen/tree/kusama
Chain Service: h​ttps://github.com/localksm/chain-service
Auth Service: https://github.com/localksm/auth-service
Documentation to test current implementation: https://drive.google.com/open?id=1CKL2GjmYBgrR-Wt3feJZd0zPk9MAl4fm 

Initial announcements in Polkassembly and Riot can bee seen here: https://kusama.polkassembly.io/motion/129 https://matrix.to/#/!QXMnIJzxlnVrvRzhUA:matrix.parity.io/$5LW4ulS1mssRdZk3FogQsVOjqP1koK3dm1MiVTadVQA?via=matrix.parity.io&via=matrix.org&via=web3.foundation

Previous on chain proposals: 
Milestone 1:https://kusama.polkassembly.io/motion/129
Milestone 2: https://kusama.polkassembly.io/motion/150

Our original proposal can be found here: 
https://docs.google.com/document/d/1M9aqGUbvZ8Ax3DMqxc7zDMUwlXG5eH680-8YnNw2W58/edit?usp=sharing

Thanks for the continued support! Best!

Milestone 3/3 (Final) - Creation of LocalKSM.com apps implementing Air Protocol for censorship resistant non custodial p2p exchange.

This is a treasury proposal whose proposer address (FyLYnuNoMAVkz1VZMMGZFHDPghQQm1916fCon1CqNt2aXbX) 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.

Stage 2 proposal is here: https://kusama.polkassembly.io/post/153

Fearless Wallet

This treasury proposal is for the fourth milestone of the - Non-Custodial P2P Trading for KSM proposal.

Details of the proposal can be found here: https://docs.google.com/document/d/1m_lBnw6zrkW980zkZhHEJ_Ny6eEUAJk9ey0GSmevleU/edit?usp=sharing

Milestone 1, 2 and 3 have now been completed.

Commonwealth thread: https://commonwealth.im/kusama/proposal/discussion/415-treasury-proposal-noncustodial-p2p-trading-for-ksm

Original Riot announcement: https://riot.im/app/#/room/#kusama:matrix.parity.io/$Ud1f2HzQuTDV3tsTVu1bp2ozFQHcX0qo_vAPztPJB4w


**Milestone 1: Reference Implementation**

https://github.com/LocalCoinSwap/kusama-reference-implementation/blob/master/Kusama%20reference.ipynb 
 

**Milestone 2: Python handler class and Python library**

Package source code:
https://github.com/LocalCoinSwap/kusama-utils 
 
Tests with 100% coverage of the library:
https://github.com/LocalCoinSwap/kusama-utils/tree/master/tests 
 
Documentation:
https://localcoinswap.github.io/kusama-utils/ 
 
Official Python package in the PyPi library:
https://pypi.org/project/ksmutils/ 


**Milestone 3: Kusama non-custodial API**

API: 
https://hub.docker.com/r/localcoinswap/kusama-api 

Automated setup documentation:
https://github.com/LocalCoinSwap/kusama-api/blob/master/docs/setup/2.-prod-deployment.md 

Questions or feedback is always welcomed.

We are excited to move on to the next milestone!

Non-Custodial P2P Trading for KSM - Milestone 4

Original discussion can be found here: https://kusama.polkassembly.io/post/118

The goal of this project is to contribute to the Kusama ecosystem by developing dedicated blockchain payment functionality including e-commerce plugins, payment APIs, a customized checkout page, and reliable payment servers with industrial standards and the highest security for both merchants and the Kusama dev community for easily integrated payments.

The detailed proposal can be found in [here](https://www.dropbox.com/s/em6dodq7ou84q41/Decentralized%20Payment%20Kusama%20Payment%20Gateway%20by%20ForgingBlock.pdf?dl=0)

This motion is for the first milestone as we discussed in here https://kusama.polkassembly.io/post/118

Decentralized Kusama Payment Gateway Development

re: https://kusama.polkassembly.io/post/128

This account is provably funded in error. We can fix this, should we? 

We have the ability to fix previously irreversible mistakes. 

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

The title and description of this proposal can only be edited by the author to explain the rationale behind it. Anyone can comment.

Kusama Wallet is an alternative mobile wallet that will allow Kusama users to interact with the network. It includes iOS and Android version and covers four groups of functions, namely user management, token management, staking and network governance. First proposal focuses on the UX/UI design and key software engineering artifacts to support subsequent phases that will focus on the development of all four functional groups.

The proposal for the first stage and the full proposal providing overview of the complete project including description of all four stages can be found [here](https://drive.google.com/drive/folders/1I-Zpmk65RLWqin2ux1EX64bzakbdnUEU).

Kusama Wallet

Updated proposal: Stand alone solution for wallets, parachains and exchanges and their users.

New Proposal: https://docs.google.com/document/d/1DpSEm3YlKVwRqiGymk1LooB3sck9RBXqN2rkVR_p6Wo/edit?usp=sharing

Demo with M1 completed: https://nomination.usetech.com/#/Nomination

New ppt: https://docs.google.com/presentation/d/1SO1-Sf-mvGwOZfgzDC70WVDfBx212lHZclWfSk_EPHo/edit?usp=sharing

Code: https://github.com/usetech-llc/apps/tree/staking-clear

Worthwhile to note that M1 and M2 form the original proposal have been implemented in M1 of this one.

Original:
We are building new Nomination scenarios for beginners and then for advanced strategies. This presentation describes the problem and a proposed solution: https://docs.google.com/presentation/d/14etktaIFTQBLNqW684qUj-6hhH59-GBJR-827WGDbBg/edit?usp=sharing.

This is the spec for the first two milestones: https://docs.google.com/document/d/1Eh-QtleAVe38IPb-tfjgv8Rlu4ANCrJld_SMMoyIxAQ/edit?usp=sharing.

The first Treasury Proposal (#19) is for Milestone 1, which is completed and reviewed by Jaco with plenty of feedback. We already fixed some of the issues raised, and plan to fix the remainder mostly during the Milestone 2. The resulting solution (upon Milestone 2) will be working as a stand alone solution. Our initial plan to integrate this solution with Apps UI has changed, as discussed in the Riot channel. While Milestones 1 and 2 are not to be changed by this pivot, further long term vision is, so we are designing a new architecture, oriented towards the specific user groups ("grandma"), and enabling integration by wallets. 
This proposal was first presented in the Kusama Direction Riot Channel on April 10, receiving a soft approval from a number of Council Members.

KSM Simple Nomination Treasury Proposal

Hello everyone! My name is Jorge Ruiz, I lead the Air Protocol team. We want to share with you our proposal for the creation of localKSM.

LocalKSM is will be an implementation of the Air Protocol to create a P2P exchange focused on KSM tokens. The project will consist of an app for iOS and Android that enables users anywhere to list proposals for selling or buying KSM at a rate they specify and with a payment method of their choice.

Our team has worked on developing a protocol for the creation of decentralized p2p markets and on/off ramps. The protocol itself is blockchain agnostic and we want to develop and implementation to support KSM as well as release the apps. This implementation would also be able to support DOTs in the future, as long as the MultiSig implementations are rollout onto polkadot.

I previously co-founded airtm(dot)com a platform for digital p2p dollars. Through it we enabled hundreds of thousands of users in LatAm to receive remittances and save their money in a stable currency. I left Airtm to create the Air Protocol, which is the result of my experience there. It is clear to us the great reach p2p have and we believe it is an essential step to further the ability of people to have access to better services and join the coming digital economy.

We would love to hear feedback from the community, both to see if anyone has put effort towards something like this before? And also to understand if there is interest on this implementation and applications.  I’m looking forward to hearing your thoughts!

Our team is very enthusiastic about Polkadot and Kusama (and in general substrate). We are planning on developing the second phase of our project with the use of substrate. As part of extending the capabilities of the Air Protocol we will be developing the Air Protocol chain which will serve as a stateful layer for our system, our intention is creating that chain as a Parachain on polkadot.

You can checkout the proposal at:

/ipfs/QmXn8A5Gng6cQKMYR8TKU2k7F2JJp8j4FjbDsi5Yn6hHir
https://ipfs.io/ipfs/QmXn8A5Gng6cQKMYR8TKU2k7F2JJp8j4FjbDsi5Yn6hHir?filename=localKSM_Proposal.md
https://drive.google.com/file/d/1wnanNcaSnv0ygLE2HDXWgzDUpbmEIhfb/view?usp=sharing

 Creation of LocalKSM.com apps (iOS and Android) implementing Air Protocol for censorship resistant non custodial p2p exchange.

Polkadot and Kusama are innovative projects with exciting ambitions. As it stands the ecosystem is extremely friendly to developers, and on a technical basis alone will be of interest to many end-users of cryptocurrency.

However, end-users of cryptocurrency typically have vastly different technical abilities to developers, and this is often a large barrier to entry standing between many projects and mainstream adoption/awareness. A typical end-user will struggle with the basic installation and operation of wallet software, and will not practice the basic security principles involved in properly securing private keys. As technical developers working in the blockchain sphere we often take for granted our own knowledge base, and lose awareness of the gap between providing the best technology, and making that technology accessible to the mainstream. Developer engagement is a critically important tenant of a crypto ecosystem, but it is equally essential we provide as many straightforward and simple on-ramps as possible to allow non-technical end-users to also participate.

LocalCoinSwap’s mission is to bridge the gap between technology and accessibility, by providing a trivially simple ebay-like system in which end users can purchase cryptocurrency directly from each other. We use decentralized technology such as non-custodial wallets and multi-sig transactions or smart-contract based escrow to protect traders from fraud or hacking, but as much as possible we abstract the need to understand the underlying technology from the non-technical end-user. Because of this, we have been especially successful in driving adoption in developing regions of the world who have limited access to traditional exchanges, and rely on other non-standard methods to enter the cryptocurrency ecosystem such as cash purchases, SMS-based payment systems, and gift-card trading. Although the UK and Australian markets constitute the majority of our volume, we are seeing large upticks across Latin America and Africa.

As part of this proposal, LocalCoinSwap will provide a platform where users can buy and sell KSM, and in the future DOT, for any local fiat currency - in every region of the world. To do this, we will extend our P2P cryptocurrency exchange (localcoinswap.com) to support non-custodial wallets and trading for these assets. Given the non-custodial nature of this implementation, there will be no platform risk with only users having access to their own private keys, no political risk as we cannot seize users funds, and a high level of anonymity for users entering and exiting the Kusama and Polkadot ecosystems.

As a project focused on creating low barriers to entry for flexible, autonomous economies, we strongly believe that a decentralized fiat on-ramp is essential for the adoption of Polkadot. Without this, users will likely have to transact through other cryptocurrencies in order to own and use KSM/DOT. As aforementioned, the non-technical end user typically finds the need to purchase intermediate cryptocurrencies an insurmountable barrier.

Upon successful completion we will provide a platform for anyone to buy or sell KSM in a secure and user-friendly manner, without any high-level technical skills. In addition, we will provide the opportunity for users to create vendor businesses in order to make money through providing liquidity, and buying and selling KSM.

We are interested in building this project as we are excited about creating mainstream accessibility to the next generation of blockchain applications.


The detailed proposal can be found here: https://docs.google.com/document/d/1m_lBnw6zrkW980zkZhHEJ_Ny6eEUAJk9ey0GSmevleU/edit# 

On chain treasury proposal - Non-custodial P2P trading for KSM

This proposal is to re-enable certain unmigrated claims in the claims module - the preimage was generated using this script https://gist.github.com/joshua-mir/b9c78bd8524cc9db2b1e36d4042aab78 based on the data linked to in the description of the gist above (scraped from polkascan) 

Fix claims

This content (and title) can be edited by the proposal author to explain the rationale behind the proposal.

batch

On chain council motion

This Treasury Proposal was to fund the Society account with 1000 KSM

The significant majority of funds in the Society account are used to pay for bids from new bidders - previously the only balance in the society was there due to donations. 

With 1000 KSM, a bid of up to that much may be accepted by the society, increasing the potential draw of bidding to join the society. If membership increases, society members can plausibly make a strong marketing force for Kusama as a whole. 

Fund the Society (executed) 

On chain treasury proposal

 Cancel enactment of a deferred slash. Can be called by either the root origin or
 the `T::SlashCancelOrigin`.
 passing the era and indices of the slashes for that era to kill.

 # <weight>
 - One storage write.
 # </weight>

 Found the society.

 This is done as a discrete action in order to allow for the
 module to be included into a running chain and can only be done once.

 The dispatch origin for this call must be from the _FounderSetOrigin_.

 Parameters:
 - `founder` - The first member and head of the newly founded society.

 # <weight>
 - Two storage mutates to set `Head` and `Founder`. O(1)
 - One storage write to add the first member to society. O(1)
 - One event.

 Total Complexity: O(1)
 # </weight>

 Reject a proposed spend. The original deposit will be slashed.

 # <weight>
 - O(1).
 - Limited storage reads.
 - One DB clear.
 # </weight>

 Approve a proposal. At a later time, the proposal will be allocated to the beneficiary
 and the original deposit will be returned.

 # <weight>
 - O(1).
 - Limited storage reads.
 - One DB change.
 # </weight>

 Remove an account's name and take charge of the deposit.

 Fails if `who` has not been named. The deposit is dealt with through `T::Slashed`
 imbalance handler.

 The dispatch origin for this call must be _Root_ or match `T::ForceOrigin`.

 # <weight>
 - O(1).
 - One unbalanced handler (probably a balance transfer)
 - One storage read/write.
 - One event.
 # </weight>

 Set a third-party account's name with no deposit.

 No length checking is done on the name.

 The dispatch origin for this call must be _Root_ or match `T::ForceOrigin`.

 # <weight>
 - O(1).
 - At most one balance operation.
 - One storage read/write.
 - One event.
 # </weight>

Referendum 71 was scheduled to be executed on block 3,200,000, and when it passed this was in already in the past. Submitting the same design as Ref 71 but as motion, since it was passed already via referenda, so we can fast track. 

This proposal will increase the validator count by 2 every 3600 blocks (1 era) 336 times (roughly over the course of 3 months).

At the end of this time period we will have a total of x+672 validators, where x is the number of validators slot once enactment of this proposal begins (in total 1172 if https://kusama.polkassembly.io/referendum/69 passes, of 1072 if it does not).

If at any point during enactment we see network stability or economics being harmed, we can cancel further increases using scheduler.cancel_named on the id this uses, 0x2b3325 (please ignore the fact this converts to +3% in utf8, I changed the parameters of the proposal based on advice and forgot to change the id).

Gradual Validator Count Ramp-up (+672 Validators/~3 Months) - same as Referendum 71 (read below)

This proposal will increase the validator count by 2 every 3600 blocks (1 era) 336 times (roughly over the course of 3 months).

At the end of this time period we will have a total of x+672 validators, where x is the number of validators slot once enactment of this proposal begins (in total 1172 if https://kusama.polkassembly.io/referendum/69 passes, of 1072 if it does not).

If at any point during enactment we see network stability or economics being harmed, we can cancel further increases using `scheduler.cancel_named` on the id this uses, `0x2b3325` (please ignore the fact this converts to `+3%` in utf8, I changed the parameters of the proposal based on advice and forgot to change the id).

this proposal has not necessarily been thoroughly game-theoried, other than a quick sanity check by Will P.

Gradual Validator Count Ramp-up (+672 Validators/~3 Months)

We need to think about how needed registrar's diversification is for the ecosystem. The council should always think of a balance between community building and security - and not having more registrars seems an unsafe approach in both directions. 

I have been working in the last days with Liebi to include the feedback the council gave to their past registrar proposal. In perspective and after the last registrar discussions, it now seems like an attractive approach, especially taking into account the changes made. 

I submitted motion 164 to the council to be voted on this new proposal and hopefully passed to the referenda queue for the community to vote after. This decision is based on 1. The need for certain degree of redundancy and the importance of the role, 2. The changes Liebi has made taking into account the council suggestions.

The amended proposal can be found here: https://hackmd.io/@WUwOYEcKS7SDniXXxl93yA/ryqHRsDaI 

Motion to add Liebi as Registrar

# Brief Introduction
Founded in October 2017, Liebi is a global-oriented decentralized financial service provider. The core team members are all from first-tier Internet companies such as Sina Weibo and Zhihu.

With the long-term exploration and accumulation of blockchain technology, it has launched a number of products such as Liebi pool, Liebi CPU lease and so on. Committed to providing safe, stable and nice experience of decentralized financial products for global users.

# Ways of Challenge
## Online Challenge
```
Fee: 1 KSM/Challenge
Regional: No Limit
Code Expiration: 12 Hours
```

- **Email Challenge**
    - Send a message containing `challenge code` and `identy info` to the challenged email
    - Use challenged address to sign email content, reply the signature to Registrar's email
    - Registrar using address to verify signature, verification success or failure
- **Social account riot\twitter\facebook etc. Challenge**
    - Send a message containing `challenge code` and `identy info` to the Social account by private message
    - Use challenged address to sign private message, reply the signature to Registrar's social account
    - Registrar using address to verify signature, verification success or failure

- **Website Challenge**
    - Send a message containing `challenge code` and `identy info` to the challenged email
    - Use challenged address to sign email content, choose one of the following methods
        - Place the signature in the website directory `.challenge/sign_message.txt`
        - Added `_dnsauth.domain TXT parsing content` using signature
    - Registrar using address to verify signature, verification success or failure

> Complete the above steps to get the `Reasonable` judgement

## Offline F2F(Face to Face) Challenge
```
Fee: 3-5 KSM/Challenge
Regional: Only Shanghai, China
Code Expiration: 48 Hours
```

- **Legal name Challenge**
    - Send a message containing `challenge code` and `identy info` to the challenged email
    - Use challenged address to sign email content, challenger print signature on the paper
    - The challenger show the `business license/IDs/passport` with legal name and signature paper to the registrar when F2F
    - Registrar completes the challenge after verifying the signature from paper

- **Reputation Challenge**
    - Send a message containing `challenge code` and `identy info` to the challenged email
    - Use challenged address to sign email content, challenger print signature on the paper
    - When the challenger participates in the `conference/workshop as a speaker offline`, challenger will show signature paper to the registrar when F2F
    - Registrar completes the challenge after verifying the signature from paper

> Complete the above steps to get the `KnowGood` judgement

## Other Judgement
If in the above judgement challenge, the challenged person has any attempt to defraud the Registrar, such as forging a phishing account, provide forged business license, etc. Once the fraud is confirmed by the Registrar, it will receive a `LowQuality` judgement.

All accounts judgement by Liebi Registrar are valid for 1 year, and need to be re-challenged after the expiration. If they are not re-challenged, they will be modified to `OutOfDate` judgement.

## Judgement Fee
```
Registrar Fee: 5 KSM (Default)
Online Challenge: 1 KSM/Challenge
Offline F2F Challenge: 3-5 KSM/Challenge
```

> Challenger can get a refund or provide an additional fee according to their needs

# Sign & Verify
- Generate Signature
    - Using https://polkadot.js.org/apps/#/toolbox/sign
    - Paste the JSON Content (including challenge code) received by email/pm/other into `sign the following data`
    - Click `sign message` to sign
    - Deliver the `signature` to the registrar for verification as described in the **Ways of Challenge**

- Verify Signature
    - Using https://polkadot.js.org/apps/#/toolbox/verify
    - Enter the challenger's KSM Address into `verify using address`
    - Paste the JSON Content (including Challenge Code) received by email/pm/other into `using the following data`
    - Fill `signature` into `the supplied signature`
    - If the result returns `success`, the verification is passed, and if it returns `failed`, the verification fails.

# Community & Partner
Based on years of community accumulation, Liebi has established a technical community of about 2,000 people. Among them are potential Validators, technical geeks, KOL and other high-quality accounts that need to be provided by judgement.

We will strictly review identity information such as Email, Legal name, Twitter, Riot, etc. Adhere to the concept of having signature characters to be trusted. At the same time, our team is mainly based in Shanghai, China. Shanghai is a city where the Chinese blockchain industry gathers, and there will be many opportunities to contact teams that require offline certification to give a KnowGood judgement.

# Contact us
Website: https://liebi.com

Email: hello@liebi.com

Apply for a new Registrar proposal description

set_code

set_max_members

set_validator_count

We're here! 

Polkadot has scheduled it's first two batches of parachain auctions, and Kusama has just ended it's second batch.

So as of right now, the plan for Kusama's parachain slots and auctions are uncertain.

**tl;dr: the reasons we were manually executing and batching auctions no longer apply, and we should run scheduled and continuous auctions going forward. I propose a continuous weekly auction that can be paused in the case of extreme circumstances. **

During discussions over the last few weeks, I think we have established that the original reason to batch parachain auctions - to monitor for instability after each batch - is no longer a pressing concern. We've also established the feasibility (albeit, with some hiccups) of scheduling auctions for the future. Polkadot is even using the scheduler to run their first two batches of auctions, albeit they are restricted to two sets of five auctions, instead of a single continuous schedule. 

I believe that, in the same spirit as Kusama's ramp up to 1000 validators before Polkadot, we should be ramping up to 100 parachains as well, ahead of Polkadot. 

There are only 48 full weeks in the longest possible parachain lease period on Kusama, so even if we had a full schedule of an auction a week continuously, forever, we'd end up with a maximum of 48 simultaneously operating, auction-assigned parachains. I see that as both a reasonable soft cap on the number of auction-assigned parachains, pending changes to the logic or rate of auctions, and a reasonable rate at which auctions should run - seeing as Polkadot seems to be implying a cadence of an auction once every two weeks (which would, if they kept up the pace continuously, lead to the same number of simultaneously operating auction-assigned parachains). Under those conditions, if we want to more properly accomplish the purpose of being a Canary for Polkadot, I'd probably even suggest shorter auctions happening more often, so that we remain ahead of Polkadot and pushing the limits of the tech - but I don't believe there has been any suggestion that Polkadot will be operating continuous auctions as of yet, so there likely will be some leeway (there is a ratio of 75% of Kusama parachain slots to Polkadot parachain slots recommended in Parity's post on the topic of the Polkadot auctions). 

All that said, I'd like to hear opinions on proceeding ahead with continuous auctions.

Here are some concerns we've already heard:

- We should not change the precedent of 5 batched auctions and a break because it subverts people's expectations.

 - We should not change the current cadence of auctions on Kusama because it will change how the incentives for auction participants play out.

 - Continuous auctions may mean that it will be harder for contributors to predict how long their contributions will be locked.

 - Continuous auctions will have less hype/fund-gathering time between them, potentially leading to "cheap" parachain slots.

- Continuous auctions may lead to crowdloan contributors locking up their funds in earlier auctions, leading to them being unable to participate in later ones. 

 - Continuous auctions might lead to uncertainty from parachain teams regarding which lease slots to target, and how to configure their crowdloans. 

The counterpoints to which are:

 - Expect chaos :) but more seriously, the initial parameters were fairly arbitrary - and we should be exploring, not sticking to an arbitrary initial precedent.

 - Same goes for game theory and incentives, we should perhaps be shifting towards long term planning and games rather than the short term sprints that batches represent. Participants should be supporting projects they want to see succeed, not guessing which project is likely to succeed and contributing to ride it's coattails - I would argue the race-like nature of batches prefer the latter, and continuous auctions need more planning on the part of teams and contributors. 

 - Slot durations and contribution lockup times are transparent and predictable, it will require slightly more communication effort on the side of parachain teams however, because these details will likely no longer be uniform. 

 - Cheap is good - we want to both grow the network and serve the purpose of somewhere with lower barriers to entry than Polkadot - that wouldn't be possible without an increase supply of parachain slots. Additionally, if parachain slots *are* highly in demand, then bids and slot bonds will reflect that with or without batching. 

 - As stated earlier, contributors should plan carefully and support the projects they want to see successful, not the projects that come into the process likely to succeed. It should not be a problem to miss out on a handful of second best choices if your favorite project wins a slot, or in other words, just like the incentives around validating and council voting work out, it should be easier for a dedicated but small community to secure space/a voice on the network than an apathetic but large community.

Parachain parameterization is something the current model allows very little flexibility in :) we see everyone aiming for the longest possible lease period, starting in the current lease period, aiming for fast contributions, which benefits a certain marketing style and business model. 

I'd like to see projects with longer term, but potentially still profit oriented goals, aim for later slots via auction (*and projects with no profit incentive, should be applying to governance for common good slots*). Or projects with more ephemeral goals aiming for a single lease period to launch their project, do their work, and spin down - issue specific temporary chain-DAOs galore. (As an aside: It would be amazing to see a hyper-decentralized DAO project that launches by spinning up a parachain for a more easily acquired single lease period, funded by standard crowdloan, which as a parachain, sets up and launches a trustless non-standard crowdloan hosted with custom terms and logic on their own chain.) Things like that are much riskier to attempt to run without a regular and continuous auction schedule, as crowdloan parameters can be left invalid and participants left hanging if there is no ongoing auction for the crowdloan pallet to bid on. 

[Sorry, that was alot of text in order to say that continuous auctions are actually easier for teams to determine parameters for than the status quo.]

Instead of / in addition to the proposal for a weekly auction, we can probably also consider: 

 - Shorter auctions. 
 - Faster than weekly schedule. 
 - Longer maximum lease period. (probably a bad idea until we are already full up). 
 - Increase in governance-assigned parachain slots. 

Things that are probably technically unfeasible at the immediate moment:

 - Parallel/simultaneous auctions. 
 - Teams bidding together and sharing capacity. 

Other thoughts and alternatives to a weekly auction schedule to stay ahead of Polkadot are welcome. 
 
The proposal for ramping up over slightly over 48 weeks to 48 parachains was made as one of the least extreme and disruptive possibilities. 



The case for continuous auctions? 

Certain community members are bringing up good points around the difficulty of productively participating in governance if someone is not a councilor - I'd like to start a thread to keep track of ideas that would alleviate this situation.

here are some seed ideas: 

* Add a "proposal queue" to council (like in Democracy) to give the general community broader communication lines to the council - this could involve a higher minimum deposit than democracy and will probably not be automatically promoted to a motion without a council member adopting a proposal - alternatively, a method for allowing Councilors to adopt existing democracy proposals as motions could serve the same purpose. 

* ensure Councilors are active and responsive to the community by punishing long-term absenteeism - the details of how to do this without skewing votes is unknown. 

* increase the size of council membership - this would likely require some punishment for absenteeism in conjunction as we probably don't want the council to lose it's velocity on Kusama.

* reduce the period of time required to turn a proposal into a Referendum in democracy - or otherwise add a mechanism to accelerate proposals from within democracy 

* replace voting in democracy with a prediction market or TCR to add positive incentives (at least at the proposal stage) for participants. 

I do not endorse any of the above ideas, I just want to see what discussion can be had around them. 



Proposals for increased community participation in governance

So this was seemingly part of the big upgrade this week - and I hadn't seen any discussion about it anywhere, so wanted to draw some attention to it.

The collective module (so, this effects council and the tech. committee) [now has a privileged member, known as the "prime" who can determine what the default vote for any abstaining voters is at the end of a given voting period ](https://github.com/paritytech/substrate/pull/5137) the Prime is currently selected as the "most popular" member (based on phragmén vote, not popular vote!) in council. 

I guess this is one solution to the problem of absentee council members ([more discussion on the topic here](https://kusama.polkassembly.io/post/28)) - if you do not vote, you are giving your decision to the most popular councilor. 

"Prime" member in council? Tl;dr

rel: https://kusama.polkassembly.io/post/28 

Here's a scalable way to get more direct representation on council for the community based on only the existing multisig functionality available on Kusama. 

## Creating a collective councilor today

A core feature of the multisig pallet is that onchain it appears to be indistinguishable from any other account (other than the fact that controlling a multisig is done purely through utility pallet extrinsics) - this means that: 

- any role that an account can participate in can be performed by a multisig account as well. 
- an account can be proved to be a multisig account to an offchain observer
- "internal" activity in the multisig is public onchain and can provide accountability to the greater community.

Presumably, one could:

- Create a multisig with the desired membership+thresholds, (fees)
- Send it's address KSM for identity, and extrinsic fees, (10locked+fees KSM) 
- Set onchain identity information, this may require using custom fields to point at the members of the multisig. 
- Signal candidacy in Council - each participant of the multisig votes (ideally exclusively) for the multisig, the multisig votes for themselves. Hopefully this is enough votes to get into the runners-up list. (locks) 
- Post multisig details in a public forum, and announce collective candidacy. This can be verified by using (threshold, membership) data to recreate your multisig address. 

From then on, any activity of this collective concilmember will require the declared threshold of it's members to agree in order to execute.

## Considerations

Multisigs in the utility pallet do not have dynamic membership, for better or worse. This means you can trust that the membership of the collective you've voted for will remain consistent, but also means that you need to create a new multisig and apply for candidacy if you do need to change the membership of the multisig for any reason. 

In addition, multisigs are not limited to any type of behavior, so members need to be collectively vigilant of a part of the multisig colluding to add a malicious backdoor via recovery - for example. 

Also, depending on the chosen threshold of the multisig, it may be less agile than a single individual councilor (there are also scenarios with lower thresholds where it may be more agile) 






On collective membership in council. 

While we already have a diverse field of mobile wallets in the ecosystem, they all attempt to be complete solutions, and we have a distinct lack of mobile equivalents to our browser extensions. 

Where we have solutions like Subsocial and Kodadot with mobile-ready UIs, users cannot use these applications with the same amount of security on mobile as they can on desktop, due to lack of an injected signer being available on mobile. 

In the longer term, the best-in-class mobile and desktop experiences come from toolkits like Web3Modal which allow developers to build experiences agnostic of the underlying signing solution used by a given user. While Polkadot Signing solutions are significantly lighter than Ethereum's - the signer doesn't require any connection to a node endpoint, the precedent is that the application provides that - it would still be interesting to explore the feasibility of remote signing solutions (portis), relayed signatures (walletconnect), and if the existing tools in the space may be reused, or if new tooling can be created within the scope of this bounty. 

One direction that is in research within the ecosystem that could lead to novel work deployed to Kusama and Polkadot is the concept of a page that stores encrypted keys in localstorage, with dapp developers loading it in an iframe and communicating with it for signatures - the idea being that the page that is loaded is specified by the user, based on their security model, up to and including a page that is hosted on localhost with a self-signed certificate as the most secure option, and a hosted wallet providing traditional username signup as the least secure option. 

REQUEST FOR CURATOR:

The Curator for this proposal should be someone at least familiar with the equivalent ecosystem components in the Ethereum ecosystem - Mobile Wallets, (ie, Metamask mobile, Trust, etc) Walletconnect, Portis, and in general the Web3Modal ecosystem. And either the ability to independently verify the safety/veracity of proposals and teams applying for this bounty, or connections to individuals that can do so (who's verification work is to be funded by subbounty, presumably).

It will be the Curator's primary responsibility to deliver a mobile-first signing solution, preferably an open standard, for Polkadot, preferably without requiring users to install an additional application on their devices so that it is platform agnostic, "as secure as possible". 

It should be clear that a Curator cannot directly be involved in the development of, or directly connected to the groups or individuals making proposals for, this bounty - although in this case knowledge of the ecosystem and relationships with the teams should probably be considered a positive factor in curators selection, so there will likely be a grey area between the two criteria. 

REQUEST FOR PROPOSALS:

I'd be excited to see the aforementioned teams and projects extending their tools to Polkadot, but ideally any team that is capable of providing a solution that satisfies the curator selected for this bounty should apply.

It is ultimately up to the curator to determine, but I would suggest using part of this bounty to fund several PoC sub-bounties that allow self-hosted solutions for app devs and users, and use the remainder to audit and polish the most promising solution(s) - Bounties can be extended via making treasury proposals to their address, and I will support increasing this bounty's funding after the first stage of PoCs

Mobile Signers / Injectors / Walletconnect equivalent 

This is a tip whose proposer address (H9eSvWe34vQDJAWckeTHWSqSChRat8bgKHG39GC1fjvEm7y) 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.