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

From my perspective, reducing the friction for onboarding high-quality full node providers, like Coinbase Cloud, makes a lot of sense for all of the good reasons outlined by Elias above.

We know from the previous posts from @AlexF - Increasing Hardware Requirements for Pocket Nodes - that the most rewards go to the “fittest nodes”. Not every staked Pocket node - whether staked as a servicer or validator - will be able to run full nodes for new blockchains as well as specialist node providers for that particular chain.

I see this proposal as a way to potentially democratise access to the highest performing nodes in a given network, while also increasing performance for end-user applications.

Some of the immediate questions that come to mind for me (in no particular order) are:

  1. How could Pocket node runners signal that they want to leverage full nodes from providers like Coinbase Cloud?

  2. How will providers like Coinbase Cloud make their decisions? Do they want to work with one or two providers? Or many?

  3. What are the centralising risks we should be aware of? And how to mitigate such?

  4. What is a fair revenue split between a staked Pocket relay node and a full node? Could potential power imbalances be exploited here? Similarly, how can we prevent too much friction in negotiations, which may ward off node providers in other networks? Other specialist node providers are unlikely to be as deeply integrated as Elias in the Pocket Network community already, so they will need to be given comfort about what they are getting themselves into.

I’d love more people to jump in with potential drawbacks - from both a technical, commercial and perhaps strategic standpoint.

2 Likes