Related Issue

https://github.com/pokt-network/poktroll/issues/612

Proposal

1. Add a min_stake_<actor> governance parameter to the application, gateway, and supplier modules.
2. Add validation logic in each respective actor’s MsgStake... handler function to assert that actor_stake >= min_stake where actor_stake is the new stake balance.
3. Update the session hydration logic to exclude applications and suppliers whose stake is less than the minimum.
4. Do nothing in tokenomics TLM(s).

Actor Min Stake Risks

mindmap
    (Actor minimum stakes)
        Gateway
            Risks
                Intentional overservicing
                Off-chain only?
            Misbehavior
                Low volume exploit
                On-chain, there are few/any? expectations of gateway actors; basically a registry to track gateways and application delegations
                On-chain, we cannot robustly distinguish requests sent by gateways from those sent by applications acting sovereignly
        Application
            Risks
                Insufficient funds to pay for services received
                Intentional overservicing
            Misbehavior
                Low volume exploit
        Supplier
            Risks
                Service/quality degredation
            Misbehavior
                No or low quality responses to valid requests for service
                Invalid/missing proofs
        

Governance Parameter Usage

These new governance params would be used in the following contexts:

1. When staking an actor; used to determine success of staking transaction (i.e. on-chain message validation).

   Source: The respective actor’s stake message handler; <actor> module.

2. When hydrating sessions; used to determine whether an actor (application or supplier) should be included in any sessions.

   Source: The session module.

3. When settling claims; used to determine whether an application should be updated/unstaked (i.e. token logic module(s)).

   Source: Token logic modules business logic; tokenomics module.

4. When a supplier creates a claim which requires a proof and fails to submit the proof.

   Source: The tokenomics module.

5. When evaluating supplier QoS (out of scope).

6. When calculating supplier stake-based rewards (out of scope).

Dependency Loop Check