# PIP-11: Implementing an On-chain Rev Share Mechanism

**URL:** <https://forum.pokt.network/t/pip-11-implementing-an-on-chain-rev-share-mechanism/1552>\
**Category:** Improvements\
**Tags:** proposed\
**Created:** [January 6, 2022, 10:18am UTC](https://forum.pokt.network/t/pip-11-implementing-an-on-chain-rev-share-mechanism/1552 "2022-01-06T10:18:19Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![Olshansky](https://forum.pokt.network/user_avatar/forum.pokt.network/olshansky/32/359_2.png) [@Olshansky](https://forum.pokt.network/u/Olshansky)\
**Post date:** [January 10, 2022, 5:08pm UTC](https://forum.pokt.network/t/pip-11-implementing-an-on-chain-rev-share-mechanism/1552/8 "2022-01-10T17:08:12Z")

</div>

Thank you for the detailed thoughts and ideas, @eliasimos. I learnt a few things myself by reading through the proposal and comments!

Though a lot of the ideas and suggestions resonate with me and arguably help both the growth and resilience of the network, I would personally like to push against it for the time being. I will defer the decision to the DAO.

## 1. **Centralization risk at the full node layer**

You mentioned this is not a risk in the short-medium term. However, I wanted to strengthen the point that Pocket is quite decentralized for a nascent network that is still being bootstrapped:

 ![Node Runners](https://forum.pokt.network/uploads/default/original/1X/dd83e32e575e3c884058a5b10339e0b736c6fcc4.png)

_Image from [poktscan.com](http://poktscan.com)_

As the community grows, documentation & infrastructure improve, it will be easier for individuals to [run their own nodes](https://docs.decentralizedauthority.com/validators/pocket#how-do-i-run-a-node). For example, [nodepilot.tech](http://nodepilot.tech) is moving fast, and I wouldn’t be surprised if they introduce some sort of node pooling (but that is outside the scope of this discussion).

## 2. Multiple Reward Addresses

> [@eliasimos](#):
>
> The Output Address could be further separated into a Custodial Address (the owner of the POKT stake) and multiple Reward Addresses (the recipients of the POKT revenue).
> 
> This solution wouldn’t be perfectly trustless because in theory the Custodial Address could unstake their node and restake without the revenue share. But the network of participants in Pocket could easily monitor this, flag it and automatically shut off service if anything is changed.

As @Andrew, this is a great addition to a business use-case, though it still doesn’t solve all the problems so it is hard to determine where a line should be drawn. [PIP-9](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351) helps increase the security of the network, which is a large improvement in the short-term.

> [@eliasimos](#):
>
> Imo this whole bundle is better left to the market to decide. Initially there will most likely be a lot of overhead in sourcing, screening, agreeing, troubleshooting etc on both sides of the marketplace. So be it I say.
> 
> Over time things will get increasingly more streamlined and possibly a lot of the complexity can be automated and abstracted away.

We are still learning around various business use cases as the market evolves, so it may be premature to implement some of those solutions in L1. For example, some node runners allow the stakeholders to configure a parameter to withdraw their POKT when earnings pass a certain threshold. It is still too early to say if business logic like this should be implemented in L1 today.

## Final thoughts

Overall, my vote is to keep discussing but defer this PIP until the network is more mature.

---

_[View the full topic](https://forum.pokt.network/t/pip-11-implementing-an-on-chain-rev-share-mechanism/1552)._