---
# System prepended metadata

title: Kick Out Voting Due Diligence V1
tags: [Proposals]

---

---
tags: Proposals
---

# Kick Out Voting Due Diligence V1

## Summary

- A lot of the effectiveness of this relates to how well performance can be tracked
- There are two problems that need to be balanced, the free-rider problem and the problem of a greedy broker

## Problems to Solve

### Free-Rider Problem

- A broker could join a stream agreement, and earn rewards while doing none of the work
- The stake and slashing is meant to take care of this, but it has to be an effective strategy

### Greedy Brokers

- If a broker or cartel of brokers decided they wanted to earn more, they could get good actors slashed/kicked out so that they instead take those rewards
- Have to have a way to prove truth in these scenarios about who is or is not a bad actor

## Due Diligence Questions

### Performance Measurement

- What is the current way that performance is being measured/what are the ways it can be measured?
- To confirm, the performance can't be easily seen by brokers in the same agreement or can it?

### Payouts

- Are the payouts still done as scoped where payments are given equally to all participating brokers or is there any stake weighting/performance weighting done?


### Compensation of Good Actors

- Is there any additional compensation for good actors? Is it just incentivized for them to kick out bad actors because they get a larger share of earnings?

### Receipts

- Is there nothing similar to a "receipt" that subscribers sign and send back for the broker to collect and put in as payment request? (which is still gameable by sybil, but could at least be somewhat mitigated with signature or some other pow)

### Stream Payments

- In the spec/past sessions, the plan was for sponsors to add money to a stream then top it up as long as they decided it was useful
- Is this still the implementation?
- Are there any payments coming from users or any changes to this?

## Possible Implementations

### Sui Model

- This model would have it be that the brokers verify performance of other brokers and they get slashed in real time.
- It could be modified so that in the case that enough stake was slashed, the broker gets kicked out
- Or after enough times that they were penalized, they are kicked out
- "Within each epoch, operations are processed by a fixed set of validators, each with a specific amount of stake delegated from SUI token holders. A validator's share of total stake is relevant in that it determines each validator’s share of voting power for processing transactions."
- "Validators observe the behavior of other validators and evaluate each other’s performance"
- "An unresponsive validator is thus doubly exposed to Sui’s incentives: they lose directly through slashed rewards and indirectly through reduced delegated stake in future epochs as stakers move their tokens to more responsive validators."
- Sources: https://docs.sui.io/learn/tokenomics/proof-of-stake

### Watchers Model

- A model where watchers are compensated for randomly querying different operators in a stream to check if they are doing their jobs
- After being flagged N number of times, that broker would get kicked out and slashed or something
- This could be good for random checks and to reduce strain on the system/needing to verify every transaction

### Time Threshold Voting Model

- Brokers in the same stream agreement can vote to kick a broker but only if they have been in the stream agreement for a certain amount of time to avoid sybil attacks
- This still has a vulnerability of a cartel of nodes kicking out anyone new each time and never allowing for new nodes to get voting power

### General Voting Model

- Each broker gets a vote and majority rules on voting out brokers
- Very easily gamed


### Stake Voting Model
- Voting is done based upon amount staked for kicking a broker
- Can align better with incentives for being dedicated to the stream
- Still can be gamed and can lead to one mega user arbitrarily kicking out all brokers (the greedy broker problem)

### Eigenlayer Model

- To be further researched