PIP33: Unleashing the Potential of Pocket as Universal RPC Provider



The calculation of relay rewards is determined by the following formula [1]

Number of relays * Relays To Tokens Multiplier * Reward Multiplier

where Reward Multiplier is determined by the node’s stake amount, and Relays To Tokens Multiplier (= RTTM) is the value of the network parameter pos/RelaysToTokensMultiplier [2].

We propose a new parameter pos/RelaysToTokensMultiplierMap so that we can set RTTM per chain.

[1] Node Economics - Pocket Network
[2] Protocol Parameters - Pocket Network

Motivation / Rationale

The operational costs of running a node can differ significantly across various blockchain networks. For instance, maintaining an archival node is considerably more expensive than operating a pruned node, and enabling debug/trace calls on a node incurs additional computational costs. That’s why Pocket Network provides separated chain IDs for an archival network and a non-archival network for some blockchains. For example, there are three chain IDs for Ethereum Mainnet, Ethereum Mainnet (0021), Ethereum Mainnet Archival (0022), and Ethereum Mainnet Archival with trace calls (0028). It’s intuitive to expect that relay rewards for 0028 should be higher than relay rewards for 0022, and rewards for 0022 should be higher than rewards for 0021. With the introduction of our new parameter, pos/RelaysToTokensMultiplierMap, we can now implement this flexible reward structure by adjusting the network parameter.

Perhaps more importantly, Pocket is an RPC infrastructure, and RPC is not limited to blockchain calls. We envision that Pocket can be used to make calls into more complex API endpoints. A good example is newly emerging generative AI interfaces such as LLMs. These endpoints cost 100 to 1000 times more per call. Proper rewarding is needed if we will make these new non-blockchain RPC chains feasible.

Finally, this also helps keeping “quiet” chains feasible. Currently, node operators are incentivized to host “busy” and established chains because performing more relays is the way to get more rewards. With pos/RelaysToTokensMultiplierMap, we can incentivize node operators to host brand new chains / quiet chains with little traffic by setting higher RTTMs for such chains.


The new parameter is added in the pos module side by side with the existing pos/RelaysToTokensMultiplier. Its parameter defines a mapping from a chain ID to a custom multiplier as follows.

  "relays_to_tokens_multiplier": "181",
  "relays_to_tokens_multiplier_map": { // <--- New
	"0028": "12345"

When a node mints relay rewards, it looks up the pos/RelaysToTokensMultiplierMap, and the relayed chain is defined there, it adopts a custom multiplier for that chain to calculate the amount of relay rewards, otherwise it adopts the default multiplier of pos/RelaysToTokensMultiplier.


Q: Are we turning our backs to our trusted traditional chains?

No. This is not a new slice in the pie, at the expense of other less computationally expensive chains. This is growing the pie, opening up new markets, new applications, new possibilities. If anything, we are growing our pie at the expense of other centralized and decentralized players who are already making progress in this direction.

Q: This is all good in theory, but who will actually use this?

Grove, currently the largest portal operator confirmed their support and demand at all levels of their company.

Q: Won’t more rewards result in more inflation?

Yes. But no. Although it is not part of this proposal, and will be decided by independent PUPs in the future, we believe that the new chains with higher-than-normal RTTM values should be non-inflationary. This can be achived by making mint equivalent to burns. If a node runner earned X POKT for a relay, the portal who brought that traffic should be charged exactly X POKT.

  • The cost to run them will be compensated entirely by the portal operators which, in turn, will be compensated by their customers. Compare this to today, where node runners are compensated partly by inflation out of nowhere.
  • Since these custom chains are non-inflationary, they can be excluded from ARR calculations.
  • Although they are not part of ARR calculations, they still serve the purpose of proving the world that Pocket Ecosystem cares about the inflation, and they are taking concrete steps towards non-inflationary models.

Q: Won’t more rewards result into more sell pressure?

Again, yes, but no if custom-RTTM chains are non-inflationary. More sell pressure, yes, but also at least the equivalent buy pressure, because portals will need to buy the tokens to burn them. Since it is non-inflationary, they will have to buy them from node runners.

We say “at least” because there is a distinct possibility faith in the future value of POKT can improve due to these exciting developments, and node runners might save some of the emission to themselves for future use, therefore increasing the buy pressure, improving the token price.

Q: Wasn’t this discussed and voted recently?

PIP-31 was voted recently, but that PIP was for 2 independent features put together and had missing details. Based on the feedback we got from the forum and the recommendations from v0 maintainers conference call on 10/10, we decided to split up the proposals, implement the feedback and repropose.

Q: I see the proposers are from a professional node runner company. Was is in it for them? Is there a hidden agenda?

There is nothing in it for them nor is there any hidden agenda. The only agenda here is making the Pocket ecosystem larger, more profitable and more competitive against other similar platforms.

Q: Is it true that only a few node runners has the resources to run gen-AI chains because gen AI is so complex?

No, it is not true. Creating gen-AI models can indeed be very difficult and R&D heavy, but by and large, running trained models is not more difficult than running a docker image. Anyone with basic container knowledge can do it. Check all these models that Pocket could run: Models - Hugging Face


  • New unit tests to verify the new features are included in the PRs we implemented.
  • We perform end-to-end testing, where we submit relays and verify the rewards are distributed correctly, on Pocket Testnet before upgrading Mainnet.
  • We prepare upgrade plan after this proposal is approved.


This proposal includes two working implementations as GitHub PRs above. They’ve been verified on our private devnet:

  • submit gov transactions
  • keep sending relays throughout a test (before/after gov transactions) and wait until relay rewards are minted
  • verify the amount of rewards


  • If this proposal is approved, and after testing has taken place for BETA-0.11.0 on Testnet, RC-0.11.0 will be published for node runner adoption. Anyone can monitor node runner adoption of RC-0.11.0 using the Servicers and Validators version pie charts displayed here or the equivalent “Staked Tokens by Node Version” chart displayed here .
  • Once ≥67% of validator power has updated to this version, an upgrade height will be selected by the Foundation Directors based on the preferences expressed by node runners (e.g. through Discord polls) and they will pass this height to the chain through the pocket gov upgrade transaction.
  • The upgrade height chosen by the Foundation Directors will be communicated in advance to ensure node runners are prepared to react if necessary. A time will be targeted that maximizes the availability of node runners, accounting for all time zones and working hours.
  • Once the network is upgraded, each of the new features will be enabled by the Foundation submitting the pocket gov enable txs and working with the protocol developers to ensure there are no issues.
  • For avoidance of doubt, this PIP does not approve any values for the new RelaysToTokensMultiplierMap parameter, which means the global RelaysToTokensMultiplier will continue to apply to all chains until a subsequent PUP is approved modifying the new RelaysToTokensMultiplierMap parameter.


Here’s an example command to change per-chain RTTMs.

export DAO=<DAO address>
export NETWORK=mainnet
$POKT gov change_param $DAO $NETWORK pos/RelaysToTokensMultiplierMap '{"0001":"12345","03DF":"42","0028":"3141592"}' 10000

Once it’s accepted by the network, the new parameter looks like this.

$POKT query node-params
2023/09/19 11:30:20 Initializing Pocket Datadir
2023/09/19 11:30:20 datadir = /home/john/.pocket
    "dao_allocation": "10",
    "downtime_jail_duration": "3600000000000",
    "max_evidence_age": "120000000000",
    "max_jailed_blocks": "37960",
    "max_validators": "5",
    "maximum_chains": "20",
    "min_signed_per_window": "0.600000000000000000",
    "proposer_allocation": "1",
    "relays_to_tokens_multiplier": "8461",
    "relays_to_tokens_multiplier_map": {
        "0001": "12345",
        "0028": "3141592",
        "03DF": "42"
    "servicer_stake_floor_multipler": "15000000000",
    "servicer_stake_floor_multiplier_exponent": "1.000000000000000000",
    "servicer_stake_weight_ceiling": "15000000000",
    "servicer_stake_weight_multipler": "1.000000000000000000",
    "session_block_frequency": "4",
    "signed_blocks_window": "10",
    "slash_fraction_double_sign": "0.000001000000000000",
    "slash_fraction_downtime": "0.000001000000000000",
    "stake_denom": "upokt",
    "stake_minimum": "15000000000",
    "unstaking_time": "300000000000"


There will be no external audit, refer to Viability.


Copyright and related rights waived via CC0.


This proposal is not available for voting:


:fire:I fully support and back this proposal :fire:

This is one of the :key:s to increasing Pocket Network’s Total Addressable Market, and will also show the :earth_americas: a use-case where blockchains can provide real value in the Web2 landscape.

Sharing a thread I posted on X after seeing @Suhail’s “super simple startup idea” which is what Pocket Network is designed to do: https://twitter.com/olshansky/status/1715433598088867844


Its great to see you in the forum. I’m fearing that these threads are not being given the attention they deserve.

I agree with this proposal too, as I said in the original post. Many issues had been addressed and some clarity was given around the subject of LLMs.
I disagree however that this proposal should be approved for the sake of AI-RPCs, this proposal is just the first step that is needed to diversify the network, no matter what kind of RPC. The proposal is useful for every kind of service that we want to provide with a different price (like archival nodes).

I would love to see more interaction from the community with this proposal and specially the other one, wich changes how the delegation works. These are important changes to the network.


Fully behind this myself. Said this offline during the last proposal but best to put it here.

Q: Are certain chains more capital and resource intensive than others?
A: If so then rewards should be weighted accordingly


Thank-you for addressing the reward aspect in this new proposal! This addresses the issue of high RTTM RelayChainIDs eating the rewards of the smaller RTTM RelayChainIDs. I appreciate the clarity :+1:

Glad to see it should be a pretty straightforward process. I assume that when a new LLM RelayChainID is announced there will be some clarity on what exactly needs to be run and configuration requirements. Good communication and transparency is all that is required to prevent any specific party from monopolizing a RelayChainID.

Thank-you for the adjustments in this proposal. Thank-you as well for making this diversification possible, as POKT should be a general data layer, not just blockchain RPC. I’m excited to see us on this path :+1:


I’m happy to see the previous proposals broken out and clarified in this way. I support this proposal in its current form.

1 Like

While this proposal passing will make it a bit harder for portals to do their business, as it introduces variable RTTM, which translates to variable pricing for us, I know it is the right thing to do for the economics of the network, and the Grove team is already planning for a world where this proposal and the associated future PUPs have passed.

I support this proposal.


This proposal is now available for voting: