<img src="https://i.imgur.com/OyL8CcE.jpg" alt="drawing" width="200"/>

# Nomi Tool Proposal
## **Nomi** is a decision support tool for Nominators in NPoS networks
Proponent: TurboFlakes
KSM Account: H1tAQMm3eizGcmpAhL9aA9gR844kZpQfkU7pkmMiLx9jSzE [turboflakes.io]
Contact: Paulo [@turboflakes:matrix.org]
Date: 29.12.2021
Requested KSM: **173.8822** / 52 960 USD (Milestone 0 and Milestone 1)

Short description: **Nomi**, by TurboFlakes, aims to engage Nominators in the community in active staking as well as improve the nomination experience, by presenting a fresh and new visual way of 1) selecting the best performing Validators in the network, 2) getting recommendations with the latest top ranked Validators and 3) displaying a contextual call to action to nominate.


## 1. Context of the proposal

Our journey began in January 2021 when we decided to deepen our knowledge of the Polkadot network with the aim of coming up with an approach that would help us, as nominators, select which validators to choose. On the other hand, by being also part of the Validator community we wanted to know how well our validator performed compared to others. This would help us raise the bar when needed, proactively keep an eye on our node and safeguard the best interests of our Nominators.

At the time, Kusama and Polkadot was an all new world for us with so much to learn that we just thought to invest some of our spare time to research and development without applying for any grant or treasury funds.

After a few months, by May 2021 we presented [TurboFlakes v1](https://www.turboflakes.com/) web app to the community in a few matrix channels and the feedback received was very good. The announcement in the matrix Kusama Validator channel and some of the follow-up reactions can be found [here](https://matrix.to/#/!LhjZccBOqFNYKLdmbb:polkadot.builders/$16221209879182SmzcG:matrix.org?via=matrix.parity.io&via=matrix.org&via=corepaper.org). At the end the Kusama Council kindly gave us a Tip ([here](https://kusama.polkassembly.io/tip/0x987eed2ea9aad82db51040586454e393026d1eec9f08618f922c5e09250629a1)), which we so well appreciated.

With this proposal we intend to further develop our tool. This includes rebranding, a new fresh look and a bunch of new cool features that we think the Polkadot and Kusama community will find useful.

### Team credentials

Paulo is a full-stack developer, with more than 16 years of professional experience on building different kinds of applications for several industries, like health and financial institutions under different kinds of technologies. In recent years, has been working mainly for start-up companies, building web and mobile applications to help them start and build their projects off the ground. Paulo’s interest and curiosity in the blockchain space is not new. With some spare time by the beginning of 2021, Polkadot just seemed to be such a cool project to invest time and learn. And so Paulo’s journey into the Polkadot world began.

Sérgio has a degree in Graphic Design and worked for almost 15 years as an Art Director in the Creative Department of some of the best advertising agencies. He was responsible for the co-creation of numerous advertising campaigns for clients from retail, health, finance, to communications, being some awarded in national and international festivals. Nowadays, Sérgio works as a freelancer in graphic design projects.

### Other Tools

We are also the creators of Crunch (GitHub project [here](https://github.com/turboflakes/crunch)), a command-line interface to easily automate payouts of staking rewards for Substrate-based chains. Crunch has matrix integration built-in so that validator operators can be easily notified about the state of their staking rewards. This project was also announced in a few matrix channels, and was very well received by the community. It has received very good adoption by some of the independent validator operators and we have also received a Tip ([here](https://kusama.polkassembly.io/tip/0x60df1707c24397210d033ff143ec2a60b709b29f4e3d396458d1918ca95f4b77)) from the Kusama Council.

## 2. Problem statement

### A brief description on how NPoS networks work

In _NPoS networks_, nominators back validators with their own stake to help them get into the active validator set. By being in the active set, validators proactively secure the network. In return, if a validator performs well they will be entitled to receive staking rewards and therefore, all nominators that proactively backed and were assigned by the _Phragmén method_ to the validator for that era also receive part of the validator's rewards.

### The Challenges nominators face

Since the _genesis_ block, there has been a growing number of validators available on the network. To get the most out of the Staking mechanism and the best reward returns, nominators need to gather information on these validators. So the question is [how does a nominator know which validators to choose](https://support.polkadot.network/support/solutions/articles/65000150130-how-do-i-know-which-validators-to-choose-)?

There's a lot of points to consider when nominating. Each validator has its own set of traits and historical on-chain performance data. Commission, own stake, era points, payouts, slashes, oversubscribe, are just a few traits to take in consideration. Also with the recent adoption of _Parachains_, validator nodes require more power and be well configured to keep up with a good performance.

In summary, to be an active nominator requires effort and dedication. And with the growing number of validators it becomes even more challenging for nominators to make an informed decision about which validators to trust and pick. Therefore, there is an unmet need for decision support tools to help nominators.

### Solutions currently available for Nominators

We believe that the vast majority of nominators do the nomination through _Polkadot.{js} portal_ and base their selection only on one single criteria - the profitability calculation. This criteria is just an estimation for the current era, based on the validator's current total stake and commission. It does not take into consideration any past era points that truly determine the average rewards the validator has been receiving. We think that nomination taking into consideration only profit is not a reasonable approach.

Some other nominators tend to stick with centralized exchanges, just because they may find the current on-chain solutions require too much effort and time.

And a few others may use some of the great solutions already developed by the community that try to solve the problem. Solutions like:

* [Validator Resource Center (VRC)](https://validatorsv2.kusama.polkastats.io/)
* [Yieldscan](https://yieldscan.app/)
* [CryptoLab](https://www.cryptolab.network)

These are all great tools. VRC provides dashboard charts about the state of the network, individual validator metrics and a ranking system. Yieldscan have their own risk level algorithm to score validators and cluster them in three different levels. CryptoLab provides validator tools, charts and focus on providing nominators with portfolio benchmark and management with four different investment strategy types.

## 3. Proposal Objective/solution/s to point 2:

Being an active community member myself, I listen and try to engage in hot topics discussed in Polkadot or Kusama channels. Something that pops up often is that NPoS networks only work if we have a vibrant and active nominator on-chain participation. What we aim to do with this proposal is to help solve part of this problem and offer to the community a different solution compared to others already available.

### Our Solution

Although we think that all the previously mentioned solutions in point 2 are complementary to each other, and help nominators to proactively be informed and participate in staking, we also think that there is space for improvement and to try different approaches.

Our decision support tool solution proposes to help nominators with the selection of the best performing validators, based strictly on the criteria they set for each validator trait.

Proposes transparent recommendations about new validator candidates that have a better ranking compared to the ones currently in the token holder nominations list.

All in a fresh new look and in a user-friendly way that aims to facilitate the nominator research job.

We think such a tool is of great value to the network and community. Since it promotes and encourages active and informed nominations. We expect existing nominators to actively participate in staking and bring new on-chain nominators to the network.

### 3.1. How does this proposal change the current logic in Kusama?

Our research and previous [web app](https://www.turboflakes.com/) showed us that the method used of selecting validators works very well for the present problem.

#### Multi-Criteria Decision Analysis

Our new decision support tool - **Nomi** - is still based on _[Multi-Criteria Decision Analysis (MCDA)](https://en.wikipedia.org/wiki/Multiple-criteria_decision_analysis)_, which is an open and transparent way of evaluating multiple conflicting traits in decision making. In our daily lives, people use it all the time without even realizing it (eg. in buying a coffee, price, quality, roast type, strength, blackness are usually some of the main criterias to consider - it is unusual that the cheapest coffee is the one hand-roasted in small batches that develops a delicious flavor). Implementing _MCDA_ as the _de facto_ method to our support decision tool just makes perfect sense. It takes into account each validator-specific trait and the level of importance assigned to each trait by the nominator. It is easy to use and helps the nominator to focus on what one feels is important and logical to s/he.

#### How does it work

The idea is to generate a Leaderboard with the highest-ranked validators at the top. These top ranked validators can be auto-selected and nominated through TurboFlakes' site.

In our current **v2-beta** version available at [beta.turboflakes.io](https://beta.turboflakes.io/#/kusama?#nomi), there are currently 10 key traits being considered for each validator:

* Inclusion rate
* Commission
* Number of backing Nominators
* Average reward points
* Is the reward payment destination as 'Staked’?
* Is currently elected?
* Own self-stake
* Total Stake
* Identity - number of valid judgements
* Number of sub-accounts or sibling accounts

Each nominator can define the level of importance of each trait in a scale of 1 to 9 - with 1 as the least important and 9 the most important. And for each trait the nominator can also limit the number of Validators to be included in the rank calculation (eg. the nominator might only be interested in Validators with commissions between 1% and 10%). For each validator the value of each trait is weighted by the level of importance assigned by the nominator.

The overall score for a validator is obtained by summing all the (weighted) values associated with their traits. After all validators are scored, the Leaderboard is created by displaying the highest ranked validators at the top.

#### Features already implemented:

Before writing this Treasury proposal, we took a step further. We decided to make several optimizations in our current codebase and implement most of our new Design guidelines. And as mentioned earlier our current site with **Nomi v2-beta** is live here → [beta.turboflakes.io](https://beta.turboflakes.io/#/kusama?#nomi).

All optimizations are fully described below under **Milestone 0**. These optimizations are tagged as [v0.2.2](https://github.com/turboflakes/turboflakes-frontend/releases/tag/v0.2.2) and [v0.8.0](https://github.com/turboflakes/turboflakes-backend/releases/tag/v0.8.0), respectively frontend and backend source code available in GitHub.

#### Additional proposed features:

#### _New Traits_

With this proposal we pretend to add 7 more traits and respective filters that are currently missing and we feel that are very important to the decision process selection:

* APY/APR - based on the average era points received
* Slashing - was the validator slashed in the past
* Average Grandpa Votes - number of grandpa votes
* Average Authored blocks - number of authored blocks
* Commission Changed - has commission changed
* Unclaimed Eras - number of eras with staking rewards unclaimed
* 1KV Participant - is the validator a valid participant in 1KV

#### _Badge system_

We also pretend to implement a badging system, where the aim is to highlight and distinguish Validators:

* Higher points badge by identifying outstanding performances, using the [Interquartile Range (IQR)](https://en.wikipedia.org/wiki/Interquartile_range) method to find the outliers in the network.
* 1KV Valid / Invalid badge
* Slashed badge
* Grandpa offline badge

#### _Leaderboard subscription_

With the subscription feature, the nominator can customize their preferences and subscribe to changes on the current list of validator candidates. As soon as the performance of the current set of validators changes, the user gets a notification with a recommendation about the new top ranked validators.

The subscription feature is a complete game changer to the current nomination experience and a must-have feature for any passive nominator to become an active one. We would even risk saying that the nominator immediately starts to be always on top of their nominations. If a new recommendation pops in, it is because something changed and it can be easily actionable with a single call to action to nominate the new set of validator candidates.

The notifications are delivered through the channel the token holder specified, and set how often these are dispatched (e.g., immediately, once a day maximum or once a week maximum). This proposal just focuses on Element (Matrix) notifications and Twitter direct messages, with a potential to expand to other communication platforms depending on the community's requests.
We pretend to store this subscription leaderboard feature (subscribed/unsubscribe) on-chain.

#### _Architecture solution improvements_

We do not aim to have any other kind of DB apart from _Redis_ and Kusama/Polkadot blockchain. The sole purpose of Redis is that having an in-memory data store we could offer a much faster and better user experience compared to constantly reading from on-chain data. Of course there are some drawbacks, since we have to previously sync on-chain data to the in-memory data store, our presented ranks in the leaderboards are not updated in real time.

Currently our backend in-sync process runs at the end of each era (every 6 hours in kusama and once a day in Polkadot). In the current [beta](https://beta.turboflakes.io/#/kusama?#nomi) version, this process takes roughly 30 minutes on Polkadot and 10 minutes on Kusama). The leaderboard and nomination features are also not available for the token holder during the synchronization phase.

We aim with this proposal to radically improve the user experience so that the token holder has access to the leaderboards or nomination feature all the time. With the latter improvement we would be in a stage where we can then sync on-chain data by the end of each session at least (every 4 hours on Polkadot and every hour on Kusama).

We also want to improve our current in-memory state so that we only keep data in sync with on-chain data from the last 84 eras.

Our current solution targets Parity archive nodes to fully sync the in-memory data store. This is also something that we would like to improve. **Milestone 3** on this proposal focuses on the installation of two archive nodes, one for Kusama and other for Polkadot and respectively operational costs.

### 3.2. Who does this solution help?

The full implementation of **Nomi** aims to help nominators to stake on-chain, be active and better informed about the most performant validators available in the target network - Kusama or Polkadot - based on their own criteria set.

For validator operators, the full implementation of this proposal is also really useful. A validator operator can search and compare their nodes with others and check how well they rank in different leaderboards. It gives full transparency on which traits may need some adjustments so that the validator can climb up on the leaderboard and safeguard the best interests of their nominators.

### 3.3. Milestones and tasks to include:

The proposal is broken into 4 milestones:

All features described in Milestone 0 are almost completed. The **Nomi v2-beta** version is currently live [here](https://beta.turboflakes.io/). The frontend and backend source code can be found here and respectively tagged as [v0.2.2](https://github.com/turboflakes/turboflakes-frontend/releases/tag/v0.2.2) and [v0.8.0](https://github.com/turboflakes/turboflakes-backend/releases/tag/v0.8.0).

If this proposal passes Council, we plan to have the **Nomi** tool available under our principal domain turboflakes.io.

We plan to continuously release the new features described below on a weekly / 2 weekly basis until all features are complete.

**Milestone 0**
Total time: 300 hours (1.5 months)

| Deliverable | Description | Hours | Completed |
| ----------- | ----------- | ----- | --------- |
| UI/UX Design | TurboFlakes site rebranding, with a new color palette, fonts and logo. Review of UI/UX of the Nomi tool, with a new interactive board, control panel leaderboard, components, validator details and mascot design. | 100 | 100%
| UI/UX Design implementation | Front-end development and backend API adjustments to fit the proposed design. Although we aim to get the site mobile responsive, we do not aim to make the Nomi tool fully operational under small mobile devices at this stage. | 120 | 80% |
| Polkadot network | Backend adjustments to allow full support of the Polkadot network and easily switch between networks. Polkadot, Kusama and Westend are all currently supported networks. | 24 | 100% |
| Filters | Backend development to implement filters for the current traits. Filters let the token holder limit the number of validators to be included in the rank calculation by adjusting the minimum and maximum normalized limits. | 40 | 80% |
| Polkadot{.js} extension integration | Integration of polkadot{.js} extension so that users can easily nominate through TurboFlakes site. | 16 | 100% |

**Milestone 1**
Total time: 362 hours (2 months)

| Deliverable | Description | Hours estimation |
| ----------- | ----------- | ---------------- |
| 7 new traits and respective filters implementation | Backend development of synchronization tasks for the following traits: APY/APR; Slashing; Grandpa votes (avg); Authored blocks (avg); Commission changed; Unclaimed eras; 1KV Participant. Update MCDA algorithm calculation to add all the 7 new traits. Normalization of respective values. Add upper and lower limit adjustments so that dynamic filters can be applied for all the 7 traits. Backend REST API update to fit all these new traits. | 130 |
| UI/UX Development | Front-end development to add 7 new weights and respective filter sliders. | 16 |
| UI/UX Badges Design | 5 different badge icons: Higher points badge; 1KV Valid state badge; 1KV Invalid state badge; Slashed badge; Grandpa offline badge; | 24 |
| Badge system development | Backend development of a badge system service, responsible for syncing and identifying the validators that deserve the respective badge. Backend REST API update to fit the validator badges. | 100 |
| UI/UX Development | Front-end development to visualize and highlight the validators with the different badges. | 32 |
| Backend architecture optimizations | Optimization of the in-sync backend process and purging tasks. | 60 |

**Milestone 2**
Total time: 328 hours (2 months)

| Deliverable | Description | Hours estimation |
| ----------- | ----------- | ---------------- |
| Pub/Sub service model | Backend development of a publisher and subscription model, where the subscriber service is responsible to permit subscribe/unsubscribe to a specific criteria set (weights and filters values). And the publisher service is responsible to publish a message about a change to a specific criteria set. Backend development of a task to store on-chain subscriptions (most likely we will be using the remarkWithEvent extrinsic) and a sync task to load such events into the in-memory data store. | 144 |
| UI/UX Design | Design of subscription flow and call to action to nominate | 24 |
| UI/UX Development | Front-end development for the subscription flow. Select current weights, filter components, notification channel and how often the notifications are dispatched. Call to action to nominate development. | 40 |
| Matrix (Element) implementation | Send push notifications to the specific user's private room. With the respective call to action to nominate/discard the recommended validator list. | 60 |
| Twitter implementation | Send push notifications to the specific user's twitter handle as Direct Messages. With the respective call to action to nominate/discard the recommended validator list. | 60 |

**Milestone 3**
Total operation costs: 1200 USD every 3 months

| Notes | Duration (months) | Price USD | Total USD |
| ----- | ----------------- | --------- | --------- |
| TurboFlakes site, hosting backend service and Redis DB (16GB Shared CPU Plan - Linode Cloud Hosting) | 3 | 80 | 240 |
| Polkadot archive node (32GB Shared CPU Plan - Linode Cloud Hosting) | 3 | 160 | 480 |
| Kusama archive node (32GB Shared CPU Plan - Linode Cloud Hosting) | 3 | 160 | 480 |

## 4. Why Kusama?

By the time of our research about the Polkadot Network, we came across the Kusama network. And we learned how important Kusama serves its purpose as a canary network for the success of all the ecosystem.

Picking up on the motto _Expect Chaos_, we knew without doubts that to start to build something, we would do it first on Kusama.

## 5. If you have seen similar proposals before: why are yours different?

Above in this proposal on point 2 - **Other Tools** - we describe similar projects that try to solve the same problem. We think our proposal brings an alternative and complementary solution to solve part of the problem.

The visualization and interactive board aims to unwind and relax the token holder from the stressful and tedious job of researching all metrics among a vast list of validators.

Some of the other tools also have some kind of alerts but as far as we know these are individual validator on-chain events. We propose different kinds of notifications. Notifications that are a recommendation, based on the token holder criteria set. The recommendation involves a new list of validator candidates that, if approved by the nominator, can be instantly transmitted on-chain.

With the full implementation of all traits (17 in total), we think we have not seen a similar proposal that covers all the metrics we propose. Also, our aim is to give full control to the user, if the token holder does not want to take in consideration some of the metrics available, those specific metrics can be disabled and are not considered in the leaderboard calculation. This is something that we also have not seen available in other similar proposals.

## 6. Payment conditions:

Since we target both networks (Kusama and Polkadot), we would like to send different proposals to both, Kusama council and Polkadot council.

We propose payment of **Milestone 0 (M0)** and **Milestone 1 (M1)** in KSM and payment of **Milestone 2 (M2)** in DOT. **Milestone 3 (M3)** to be submitted to both councils every 3 months, with Polkadot council the first to receive the submission.

Note: To calculate the price, we will be using the [30 day avg tool by Subscan](https://kusama.subscan.io/tools/price_converter) on the day of each submission.

Total USD cost: 79 200 USD
Hourly rate: 80 USD
Total team estimation hours: 990 (300+362+328) (~4/5 months for completion)

* **Milestone 0** and **Milestone 1**
* Total USD cost to be submitted to Kusama Treasury: 662 hours * $80 = **52 960 USD**
* Total KSM: **173.8822** (using 304.574 KSM Price (USD) calculated on 29/12/2021 by EMA30 on [Subscan](https://kusama.subscan.io/tools/charts?type=price) )
* **Milestone 2**
* Total USD cost to be submitted to Polkadot Treasury: 328 * $80 = **26 240 USD**
* **Milestone 3**
* Total USD cost to be submitted to both treasuries every 3 months: **1 200 USD**

We plan to submit this proposal to cover the costs presented in M0 and M1 to the Kusama council. We plan to finish M0 and start M1 straight after as soon as this proposal is approved by the council.

After M0 and M1 completion we plan to make a report that will be shared on Polkassembly and Kusama Direction. We plan then to follow up with a new proposal to be submitted to the Polkadot council regarding the costs of M2.

After M2 completion, again we plan to make a report that will be shared on Polkassembly and Polkadot Direction, and to follow up with a new proposal to be submitted to the Polkadot council regarding the operation costs described in M3.

## 7. Comments, Qs&As
--

## 8. We'd love to hear about how you got to know about the Kusama on-chain treasury: let us know, in a few sentences, how did you become familiar with the spending mechanism and the on-chain treasury?

When we were researching the Polkadot ecosystem, the Kusama/Polkadot on-chain treasury was a tool well described in the Polkadot wiki. We have since followed both Direction channels on the element where proposals are discussed, so that we could participate and learn how to submit a proposal to fund our project one day.