---
tags: Proposals
---

# Kick Out Voting Proposal V2

## Summary

This second version of the proposal improves on V1 by adding in the concept of positive reputation, improving on the logic and also allowing for sponsors to flag brokers for further audit.

## Entities

- There will be a new entity of "watcher" which are users who earn rewards for watching the network

## New Parameters

| Name | Description | Type |
| -------- | -------- | -------- |
|maximum_flags|The maximum number of times a broker can be flagged before they are kicked out|Integer|

## New Local State (Broker)

| Name | Description | Type |
| -------- | -------- | -------- |
|number_of_flags|The number of times a broker has been flagged in streams|Integer|
|sponsor_warning_boolean|A flag which can be activated when a sponsor flags a certain broker to increase likelihood of audit |Boolean|
|number_passed_audits|The number of audits which a broker has passed with success|Integer|
|age|The length of time that a broker has been in the system|Integer|
|reputation|A score of reputation that can be updated when someone calls for it and used for purposes of checking which broker pools a delegator might want to stake in, or other needs|Integer|

## Functional Parameters

| Name | Description | Type |
| -------- | -------- | -------- |
|weighting_scheme|The function which determines probabilities of being audited for each node|f(number_of_flags, sponsor_warning_boolean)|
|reputation_score|The function which can compute a score of reputation for a broker|f(number_of_flags, number_passed_audits, age)|

## Behavioral Actions/Prior Actions

### Query Brokers

- This behavior is called by the watcher
- This is the behavioral action where a watcher signals they are ready to query brokers and earn rewards
- At this stage, the specific broker to query has not been decided and it triggers the policy for choose broker

### Mark Broker for Audit

- This behavior is called by the sponsor to increase the likelihood that a broker is going to be audited in the future
- It leads to Mark Broker Policy afterwards

### Check Reputation Score

- This policy could be called by anyone willing to pay the gas and would re-calculate reputation score for a broker
- It would lead to the Check Reputation Score Policy being called

## Policies

### Select Broker to Query

- This policy would define which broker a watcher is going to observe
- The implementation for the base case is a random broker each time, and a random stream each time
- The selection under complete randomness could be something like:
- index = current_time_stamp % number_of_brokers
- current_broker = brokers_in_system[index]
- number_staked_streams = number of streams that current_broker is in
- index2 = current_time_stamp % number_staked_streams
- stream_to_query = current_broker_streams[index2]
- This would pass along a message of which broker and stream the watcher would query against and would give a pseudo-random selection
- The randomness can be extended to have unequal weighting and use the weighting_scheme() function to bias towards certain brokers being more likely to be picked.
- For example, all else equal, brokers with the sponsor_warning on could have double the chance of selection meaning index i or index i + 1 might lead to their selection. Of course this would need be fleshed out in terms of what algorithm exactly would do it for speed, but the main idea stays the same.
- The query broker policy would be called afterwards

### Query Broker Policy

- This policy would take the watcher, the broker, and the stream ID and then create the logic of what would be tested
- There might be considerations towards size of data differences etc.
- The logic of this policy would be:
- Determine the test query form
- Determine the rewards that should be allocated to the watcher based on test query computational work
- Run the test query and parse the response into query response message
- Call the "Watcher Reward Policy" and "Watcher Query Response Policy" passing along the messages

### Watcher Reward Policy

- This policy would deal with how rewards are given to watchers
- There is many considerations including vesting, timing of payments, bundling of payments, etc.
- For the moment we will assume it is a simple policy that takes the reward and immediately pays out
- The mechanisms that are called afterwards are:
- Increase Watcher Funds
- Decrease Stream Funds

### Watcher Query Response Policy

- This is the policy which takes care of the query responses
- A simple logic would be:
- Take in a message about success of the query to the broker
- If it is a good response, then call the "Record Passed Audit" mechanism and terminate the function here
- If it is a bad response, call the mechanism "Record Flag" for the stream and broker
- Check the number of flags on the broker
- If number of flags is greater than the maximum_flags parameter, call the "Kick Broker" mechanism for the broker/stream combination

### Mark Broker Policy

- This is the policy that just determines if a broker warning should get added
- One possible implementation is to have a time before a broker can be flagged after the latest warning was added to try and prevent abuse of the system
- If the warning is allowed to be added, the Add Broker Audit Warning mechanism is called

### Check Reputation Score Policy

- This policy calls the reputation_score() function on a given broker and then returns what the value is
- The Update Reputation Score mechanism is called afterwards

## Mechanisms

### Increase Watcher Funds

- This mechanism will take in an amount of funds that should be allocated to the watcher for their work and increase their funds by this much

### Decrease Stream Funds

- This mechanism is the counter to "Increase Watcher Funds", it is the stream paying out the funds as compensation for ensuring the brokers are doing their job

### Record Flag

- Given a broker i/stream j combination, this will increase the number of flags for broker[i] @ stream[j] by 1.
- This will require adding a new variable to the stream to track flags

### Record Passed Audit
- Given a broker i/stream j combination, this will increase the number_passed_audits for broker[i] @ stream[j] by 1.

### Kick Broker

- Given a broker i/stream j combination, this will do the following:
- Slash broker[i]'s stake completely
- Kick the broker from the stream
- Possibly add them to a list of banned accounts

### Add Broker Audit Warning
- This mechanism takes a given broker and sets the attribute of sponsor_warning_boolean to True

### Update Reputation Score
- This mechanism receives the reputation score from the check reputation score policy and then updates the score for the broker

## System Guarantees

1. All brokers have either an even chance of being selected for the query or a "fair" as defined by the weighting scheme chance of selection
2. Sybil attacks to kick out a broker actually doing work are not easily done
3. There is a way to keep track of past infractions
4. Doing the work is rewarded by higher reputation