---
tags: Proposals
---

# Kick Out Voting Due Diligence V2

The following are general topics with questions and ideas which would benefit from input from the streamr team.

## General Question

- Is the watcher with either querying or receipts model the best option?
- Is a simple voting pattern possibly less accurate, but better for V1?

## Rewards

- The current implementation has rewards earned by amount staked, but does that translate to the broker doing more of the work overall?
- Put another way, if a broker has 70% stake, does/should it do 70% of the work or do all brokers do the same amount of work?

## Defining Malicious Behavior vs. Network Troubles vs. Broker Problems

- Is it possible that a broker is doing their job but all of their neighbors fail them and that is why the message doesn't go through?
- Is there a way to account for broker specific troubles, like, say a power outage? Once a broker is flagged can they be checked daily/weekly for some time period to see if it was one off versus malicious?
- Would a system where probability of being audited be related to the number of times one is flagged be a good way to over time track things like this?

## Use of Voting

- There are three options for how kicking out could work:
1. Algorithmic where N flags causes a kick out automatically
2. Algorithmic where N flags leads to a broker vote for neighbors to decide
3. Discretionary where flags are recorded but broker's can vote at any point, flags are just used as signal
4. Discretionary where sponsors are able to kick a broker out if they have N or more flags

## Watcher Service Opt-In

- Would it possibly be a good idea for sponsors to opt-in to watcher services
- On one hand this could reduce the burden of checking to be only in streams where a sponsor thinks the brokers are not doing the work
- On the other hand, it might make it difficult to attract watchers if the demand isn't consistent or large

## Sponsor Targeting

- Open question of whether sponsors should be allowed to either directly target brokers or hint at brokers that might not be performing
- Could this mechanism be abused?

## Blockchain Level Question

- On a blockchain level, brokers are registering for bounty with their address. How is this mapped to network identification? Do we know exactly who is a broker and who is a regular node? Also: Can any node identify the entity type of other nodes? Would a broker be able to tell watchers apart from regular nodes, other brokers from regular nodes etc.

## Positive Reputation

- Potential to use random checks to build up long term reputation
- Brokers being queried and responding well could accumulate reputation to not be checked too easily, reducing overhead.
- Brokers could potentially gain preferential access to bounties through reputation, especially if bounty is oversubscribed (if that happens at all, since rewards should be balancing already)

## Receipts vs. Queries

- In general, there are two possible implementations, one with a query based system and one where receipts are checked
- Receipts is under development but not yet complete
- Is it better to start with the query system as the baseline, or would integrating with the research for receipts be better?
- Query system is likely the easier version at the moment to implement

## Watcher Discoverability

- Would it be easily discovered that a query came from a watcher?
- If you only expect 4 neighbors to query and all of a sudden a watcher is querying, would it be obvious?

## Payment of Watchers

- Watchers likely would be best paid from the stream
- Should it only be when a broker has been found to not be doing the work?
- Should there be baseline payments no matter what since knowing that brokers are all working is also good
- Should there be a combination of a baseline payment plus bonus for finding bad actors?
- It probably is better to have just baseline so that watchers don't have an incentive to lie and get brokers kicked out

## Reputation Rewards

- One possible way to deal with the issue of brokers being kicked out and coming back with a new identity is to have rewards also possibly be a function of reputation
- This would make it so that a broker would also fear being kicked because it could impact future earnings

## Global vs. Stream Level Flags

- The times a broker is flagged in a stream are of course important, but it could also be useful for global flags
- Could increase the odds of audit in other streams if a broker is flagged in one
- Could also be a consideration to kick the broker entirely from the ecosystem if they are found to be in violation across many streams

## Watcher Payment Incentives

- Question 1: Does the idea of a stream paying out from their funds for the watchers after each query that happens make the most sense?
- Original Jakob comment: from stream funds or bounty funds? In my understanding, a stream can have many bounties, and brokers stake to a bounty. I guess this terminology might be used interchangeably though. This raises another point though - what if a sponsor does not want his funds to be used for this service, but then random watchers are allocated and “drain” his bounty? Maybe when starting a bounty, the sponsor could have an opt-in/opt-out to this watcher service, which removes it from indexing? Might be high overhead for an edge case though, but could keep in mind.
- Question 2: Does there need to be a different reward for finding bad behavior so watchers are incentivized to actually look for these behaviors vs. just flag randomly and not do the work?
- Original Jakob comment: no matter whether the result is positive/negative? If result does not matter for payment, watchers will be less incentivized to flag negatively (or might even flag randomly - might want to think about whether the query response can be proven/challenged) and sponsors marking brokers for audits will know there is a cost even if the broker is not malicious (which is good, since it drives down sponsors flagging brokers arbitrarily)

## Reputation Updating Frequency

- One design question is whether after every update to passed audits, flags, etc. that reputation should be updated and stored.
- Would probably depend on the complexity of the reputation score calculation, and this is more a down the road question