---
# System prepended metadata

title: Broker Self-Staking Proposal V2
tags: [Legacy]

---

---
tags: Legacy
---

# Broker Self-Staking Proposal V2

## Summary

The following is a more refined and improved proposal from the [original](https://hackmd.io/NxWiJGdyTFC4dQPPwCS7HQ) proposal. The parameters, behavioral actions, policies and mechanisms that would be implemented are described below (at the modular level without specific implementations). As well connections to The Graph and system guarantees are shown below. 

## Parameters



| Name | Description | Type |
| -------- | -------- | -------- |
| initial_margin     | The initial margin requirement that is needed from the broker to create the pool     | Pool Token     |
| maintenance_margin     | The margin that has to be maintained      | Pool Token     |




## Behavioral Actions/Prior Actions

### Broker Pool Initialization

- On initialization of the broker pool there is an <code>initial_margin</code> of tokens that the broker must be buying in to. The broker transfers the necessary DATA to pay for the tokens and receives them in their account.
- This whole flow can follow through the same format as a normal buying operation for a delegator except we track the variable of broker stake separately

### Broker Stake Withdraw

- A behavioral action where a broker sends a message to opt to withdraw stake.
- The flow is Check Withdraw Ability -> IF TRUE -> Withdraw Self-Stake

### Broker Stake Slashing

- In the event of slashing for bad behavior, poor stream performance, or other reasons, there can be slashing that occurs on the broker end
- This will trigger "Check Under Funded" to possibly trigger the flag for being underfunded


### Revenue Modification

- In the event of a broker's stake being under the <code>maintenance_margin</code>, they will have their revenue diverted to filling back up the stake

### Broker Stake Top Up

- This is the event where a broker tops up their self-stake

## Policies

### Check Withdraw Ability

- A policy which checks the ability of a broker to withdraw their own self-stake based on conditions

### Check Under Funded

- A policy which checks if the current stake that a broker has is less than the <code>maintenance_margin</code>
- This will divert revenue until the stake is back to variation margin
- It may set a variable to True which means that is underfunded until the value is above the <code>initial_margin</code>

## Mechanisms

### Withdraw Self-Stake

- A mechanism which decreases the pool tokens of the broker and swaps DATA to them

### Top Up Mechanism

- A mechanism which takes care of setting any flags, transferring for pool tokens, etc.

## Connections to the Graph
- The brokers in Streamr are analogous to indexers in The Graph.
- Indexers are required to put down an initial minimum stake in order to be eligible to receive delegated stake. Indexers may collect delegation up to a set ratio of the stake the broker provided. The `max_delegation_ratio` in The Graph is 16.
- There is an auto-stake feature that indexers can use to have their rewards be automatically added to their own stake. This increase in their own stake, allows the indexer to take on more delegation, assuming they are near the `max_delegation_ratio`. If an indexer needs to use their own rewards to pay for their operations, wishes to take profit, or use their rewards elsewhere, then they would not use this feature.
- Similar to the proposal here, the indexers stake is subject to slashing. The delegators to that indexer are not subject to slashing, but the delegation will not earn rewards for that period.

## System Guarantees

1. Brokers will only earn revenue if they have enough stake.
2. Brokers will be the first line of defense for slashing

## Open Issues

1. How should the underfunding be taken care of, should there be a flag that gets set to True once margin is under maintenance margin and gets set back to False after above initial margin?


## Path to Implementation

1. Come to consensus on this proposal
2. Update mathematical specification with new features
3. Update and work out example scenarios
4. Update and re-run the cadCAD model for validation