---
tags: Proposals
---

# Constraints for Kick Out Voting Proposal V5

## Parameters to Set

- The following are the parameters that are important to the simulation and should be considered in the constraint process

| Name | Description | Type |Constraint |
| -------- | -------- | -------- | -------- |
|number_peer_broker|The number of peer brokers which are assigned to a flagged broker when a flag is raised|Integer|Overhead of choosing many brokers|
|number_peer_voters|The number of peer broker votes which are potentially counted for peer-review (so if this is 7, we only pay for the first 4 agreeing votes)|Integer|Overhead of voting + time to conclusion|
|amount_stake_flagging|The amount of tokens a flagging broker has to allocate from his bounty stake to pay for peer-review service if his flagging is incorrect|Integer |1. Amount must be large enough that there is some risk to flagging incorrectly 2. The amount must be small enough that brokers have enough stake to be able to flag when they see it|
|amount_payment_reviewer|The amount of tokens a reviewer gets if he votes with the majority and his vote is counted |Integer|1. Amount must be large enough to make sure reviewers are fairly rewarded and want to act correctly 2. Amount has to be small enough that the payments can be given|
|amount_payment_flagger|The amount of tokens a flagger gets if his flag was found to be correct by majority vote |Integer|1. The amount needs to be constrained so that there is still enough funds to pay out the reviewers|
|percentage_stake_slashing|The percentage of the broker stake that is slashed if they are voted guilty |Percentage|1. The slashing amount needs to be enough to take care of all the payments 2. The slashing amount can't be too aggressive that a false-positive ruins a good broker 3. The percent needs to be large enough so that the minimum stake times percentage is not too small|
|max_duration_time|The amount of time that a vote must have been live for before it can be cancelled with the Cancel Flag behavior. Can be called by anyone to resolve votes that did not resolve. |Days/Hours|Duration should allow for reasonable voting time while not encouraging voting processes that are not terminating |

- Bounty has total funds, which are paid out as allocations based on current stake. A freerider receives allocations proportional to own stake vs total stake in bounty. Other brokers in bounty lose these allocations to freerider.
- The expected payoff for voting should not differ depending on the outcome of the vote.

### Voting:

**Max votes:**
- If x out of y votes are needed (say 4 out of 7), and neither later votes nor non-majority votes are rewarded, we will always pay x reviewers.
- Each vote spends gas fees and computational overhead for voting.
- If number_peer_broker is much higher than number_peer_voters we risk many brokers spending gas fees and computational overhead without receiving payment.

**One Reviewer:**

Gas fee + computational overhead < Reviewer Fee

**Majority not-guilty vote:**

x * Reviewer Fee < Amount_stake_flagging

**Majority guilty vote:**

x * Reviewer Fee + Flagger reward < minimum stake * slashing%

### Voting with Probabilistic View of Error

- If we want to include the possibility that the vote does not end or the majority votes incorrectly, then we would define the constraints like so:
- Take P(E) as probability the voting is cancelled and ended early
- Take P(I) as probability of incorrect voting
- It is only going to impact the individual reviewer constraints

**One Reviewer:**

Gas fee + computational overhead < (Reviewer Fee) * (1 - P(I) - P(E))

**Majority not-guilty vote:**

x * Reviewer Fee < Amount_stake_flagging

**Majority guilty vote:**

x * Reviewer Fee + Flagger reward < minimum stake * slashing%

### Flagging Stake:

- amount_stake_flagging must be:
- high enough to deter griefing
- low enough to not deter valid flags

**Incentives for Flagger**: Flagger reward + allocation benefit from kicking out other broker

**Allocation Benefit:**

Flagging Broker: Holds y% of bounty stake which yields y% of allocations (A)
Flagged Broker: Holds x% of bounty stake which yields x% of allocations (A)

When a broker is kicked:
- Flagger allocation increases by a factor of 1/(1-x) of A
- This is likely to be temporary as other brokers may stake or join noticing how much more profitable the stream now is
- Local view: excess funds returned to bounty, so A increases by slashing - fees

|Flagger | Guilty | Not-Guilty |
| -------- | -------- | -------- |
|**True**| P(T, G) * (Flagger Reward + Allocation benefit)| P(T, N) * (-Amount_stake_flagging)|
|**False**| P(F, G) * (Flagger Reward + Allocation benefit)| P(F, N) * (-Amount_stake_flagging)|

- If Reviewer Fees are not biased towards voting outcomes we should expect False Positives and False Negatives to be equally likely (since voting is automated).
- If: amount_stake_flagging > Flagger reward + Allocation benefit
- we should see flags raised only when there's some confidence of guilt or additional value not priced in ("I like to pay for griefing", "I value my money less than this dude's money"), as in all other cases the expected outcome is negative (if false positive and false negative are equally likely)
The higher the amount_stake_flagging is than the rewards, the higher the confidence of guilt or additional value not priced in must be.

**Juuso thoughts:**
amount_stake_flagging > P(False Positive) * (flagger reward + allocations benefit from kicking out a major staker) * safety multiplier
you can’t actually profit from false flagging, or even close

amount_stake_flagging > P(False Positive) * Slashing Risk Amount * safety multiplier
it must be a lot more expensive to raise false flags until you get a false positive, than the target will lose

### Timeline / life cycle of a flag:

| What | When | Description |
| ------------------- | -------- | -------- |
| Flag raised | `Bounty.flag` called | |
| Reviewers chosen | in the same transaction | |
| Start review | when reviewers notice an event | |
| Grace period? | before voting starts? | Flagged broker gets time to come back online and resume brokering |
| Voting starts | after desired review time | There should be enough time for a review (that we pay for, after all) |
| Flag cancelled | after `min_flag_cancel_time` | |
| Voting ends | after last vote is cast so there's a quorum?| | Pay the reviewers/flagger | in the same transaction? | |

max_duration_time:
flag raised ... reviewers chosen ... voting period ... grace period ... termination

max_duration_time > t(reviewer choice) + t(review voting period) + t(grace period)

## Example values:

### Jakob
https://docs.google.com/spreadsheets/d/1IgMkT1hyqvzC8b1EkthL0jBSxJAZ5Y5HrJFROK_4Cgw/edit?usp=sharing
Assumptions:
36% APY? -> $1000 Stake earns $360 -> $1 per day
(roughly current APY while incentivized purely by Streamr and without bounties, have to assume this will go down when people actually have to pay for stuff)
Slashing: 10% of Stake
Total Bounty Stake: $10000
Allocations: $3650, $10 per day, (currently) $1 per $1000 stake per day
Min Stake: $100
Min Slashing: $10
Votes in agreement needed: 4
1 Reviewer Fee: $0.25 (equal to daily allocations for $250 stake = 2.5 days min stake allocations in this bounty)
4 Reviewer Fees: $1

Flagger Reward: $4 (daily fee for $4000 stake, 40 days min stake allocations)

Flagging Broker Stake 1 = 100 ($0.1 a day)

Large flagged Broker, small flaggin broker
Flagging Broker Stake 1 = 100 ($0.1 a day)
Flagged Broker Stake = 5000 ($5 a day) (500 slashed, all removed from bounty)

Total Allocation Benefit =
Total Bounty Stake reduced to $5000
Allocations increased by $495 to $4145 -> $11.3 per day -> $1 per day per $440.2 in stake, short term raise to 82% APY

Flagger with $100 initial stake now has $104, which now earns him $0.23 a day

Majority not-guilty vote:
x * Reviewer Fee < Amount_stake_flagging
Majority guilty vote:
x * Reviewer Fee + Flagger reward < minimum stake * slashing%
amount_stake_flagging > Flagger reward + Allocation benefit

### Juuso
1 < 10
Reviewer fees 1 USD
Flagger reward = flag stake = 10 USD
1 + 9 < 10
Slashing% = 10%
Minimum stake 100 USD
would get slashed worth 10 USD
Here flagger reward must be capped to 9 USD
also would cap flag stake
10 > 5% * (10 + 20) = 1.5
P(False positive) = 5%
Allocations benefit = 10 days * (1 USD/day * 2) = 20 USD
i.e. false positive throws out half of total stake for 10 days, so while I normally make 1 USD/day, for the next 10 days I’ll make 2 USD/day
Safety multiplier = 1
seems to work with these numbers… though I guess “safety” here means how many times less profitable we want to make abuses

250 >= 5% * 5000
Slashing risk amount = 50 000 USD * 10% = 5 000 USD
for the biggest staker
Flag stake would need to be proportional to the Big Stake
potential problem! No one can afford to flag the Big Staker
Maybe slashing should be capped, too?
slashing could be min(0.1 * stake, 20 * flag stake)?
Note no room for safety multiplier here
Maybe review can be a LOT better than 5% false positives?

tldr: we shouldn't allow expected 1:1 griefing by false flagging (and false positives), and at the same time we want it to be possible to flag and kick out the Big Staker. We can have both by capping the slashing by some multiple of flag stake.