Staking contract architecture

Phase before FlowMint: Bootstrapping clusters in the absence of enough gateways to sign receipts

Requirements

  • Clusters will join as a single entity and stake
  • Stake should be more than a minimum for them to be active
  • Any one with POND/MPOND should be able to delegate their stake to clusters.
  • Clusters need a minimum amount of MPOND staked/delegated to be considered active in the registry
  • Reward that cluster receives is distributed to the people who delegated stake weighted by the amount of stake. The calculated reward will be given to the delegator after the cluster takes a commission.
  • Clusters can be configure their commissions (its not fixed)

Staking contract

  • Users can lock their stake with a staking contract and delegate it to any cluster.
  • Users can create multiple such stake locks and delegate to different clusters.
  • User can undelegate their stake
  • Undelegation involves a certain bonding period
  • User can redelegate undelegated stake
  • User can withdraw stake

Cluster contract

  • This contract manages the clusters, their info like commission percent and reward address.
  • Manages cluster entry and exit
  • Calculates total stake with cluster and it’s delegators

Performance registry

  • This registry provides the performance information of every cluster which was active during the last epoch.

Distribution Contract

  • Rewards will be fixed for an epoch
  • Based on the data from performance registry and stakes of the cluster, rewards are distributed
  • Rewards can be claimed by delegators less the commission of the cluster
  • Cluster owner can also claim rewards (including commissions from delegators)

FlowMint: Bootstrapping gateways

Read more at https://hackmd.io/vxEd8aLBRL-Gcj4RVokZ5g?view API: http://34.93.40.96:3001/api-docs/

Phase after FlowMint: After enough gateways have joined the network

Types of Actors

  • Delegators: Users who have tokens and would like to judiciously delegate their tokens to relayers so that they can gain part of their service rewards.
  • Pools: Token pools where delegators can (but don't need to) stake and pool (enables staking companies to run multiple relayers without having their delegators to use different addresses for different relayers - can just have 1 pool address as the interface)

Requirements

  • Users who have tokens can delegate them to relayers in 2 ways
    • Directly delegate to relayers
    • Delegate them to Pools which delegate to relayers on behalf of the users
  • Users who delegate tokens to relayers get rewarded a fraction of what the relayer earns.
    • fraction is decided by relayers
  • Some tokens from the stash account are bonded to a controller account
  • Controller account controls all non funding operations onchain
  • Stash account that holds all the balance and involves adding more funds
  • Session keys that are the keys with which the relayer signs. The session keys need to be set by sending a tx from the controller account. Session keys are what binds controller to the relayer.
  • Rewards earned can behave in the following ways
    • Go to stash and staked to self
    • Go to stash and staked to someone else
    • Go to controller
    • Go to a payment address
  • Set a proxy address which can do the following
    • Any action
    • Non transfer
    • Governance
    • Staking
  • Set onchain identity for the address

Actions

  • User has tokens
  • User has to bond those tokens to a controller to begin staking. Once bonded that money is locked.
  • Same controller can’t be used for 2 stashes
  • Controller has control over unbond funds and everything else
  • Stash address can add funds and change controller
  • Same stash can’t have 2 controllers.

Architecture

Stashing Contract
  • Users can send tokens to the stashing contract and set a controller.
    • Controller can be same or different than stashing address but different is recommended
  • Same user can create another stash with another controller. But not with same controller
  • User can add funds to an existing stash
  • Once a stash is created, it can be delegated to another address by the controller.
  • If not delegated the stash is not delegated to anyone by default.
  • You can create stash and delegate in one go as well.
  • Users can unbond tokens to a stash, there will be a waiting time based on the waiting period for relayer unbonding time.
  • Once unbonding time is done, user can withdraw the tokens
  • When a stash is created, the user has to specify how the rewards for this needs to be distributed.
Allocation Contract
  • When a user delegates to another address, this data is added here.
  • The delegated address can stake it to any relayer or a group of relayers
  • If multiple relayers are delegated to, then incase of any addition of stake. It will be unallocated to any of the existing relayers unless specified.
  • The unallocated stake can be allocated by the delegated address to any of the existing/ new relayers.
  • In case of withdrawal of stake, the last relayer to whom stake was added, will lose the stake. Delegated address can specify the relayer to withdraw from first as well.
  • If user delegates to self, then also user has to set the relayer in the allocation contract
  • Any changes to the stash (add/remove) will be reflected in the allocation contract
Relayer Contract
  • Gets the stake data from allocation contract and maintains cluster to relayer mapping
  • Relayer should be able to join cluster, if min req are passed
  • If the allocations are updated due to funds being bonded and unbonded, that should be reflected here.
  • Cluster contract needs to be created beforehand for the relayers to join it.
  • Relayers can add the session keys which will be used by nodes here.
Producer Contract
  • Producer contract stores the producer account and the mapping to the session keys of producer
  • A type of stash account can be created for producer as well
  • Stash account will have a controller attached
  • Stash account can be allocated to producer for producer staking