PIP-31: Unleashing the potential of POKT



We propose two consensus breaking features to improve v0 experience.

  1. Per-chain Relays To Token Multiplier
  2. Built-in Reward Share feature

Feature 1: Per-chain Relays To Token Multiplier


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.

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.

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

Feature 2: Built-in Reward Share feature


We suggest introducing a built-in reward sharing feature that enables a staked node to distribute block/relay rewards across multiple wallets with the percentages defined per wallet. Node operators can leverage this functionality to offer a reward sharing pricing model.

Motivation / Rationale

The Non-Custodial Staking feature [1] reduced the security risks associated with staked funds being held in the custody of third-party node operators. From the standpoint of node operators, however, non-custodial staking and a reward share pricing model do not coexist naturally because the service rewards are now in the custody of customers. A bad-intentioned customer can abscond with rewards, and a node operator would have no recourse to recoup the losses (except for legal action, which is costly and in some cases impossible internationally). This can be a barrier for node operators to fully go into non-custodial staking.

This also helps reduce the number of transactions in the network because with this feature, commission transfers happen without issuing send transactions. To facilitate zero-maintenance non-custodial staking, we also included fixes of minor issues —namely, negative rewards and operator topping-off— in this feature, as detailed below.


The built-in reward share is achieved by introducing a new field delegators in a staked node side by side with the existing output_address field as below, which defines reward share percentages for multiple addresses.

type Validator struct {
  Address                 sdk.Address
  PublicKey               crypto.PublicKey
  Jailed                  bool
  Status                  sdk.StakeStatus
  Chains                  []string
  ServiceURL              string
  StakedTokens            sdk.BigInt
  UnstakingCompletionTime time.Time
  OutputAddress           sdk.Address
  Delegators              map[string]uint32 // <--- New

For a servicer to earn relay rewards from a single evidence submission, its operator address needs to submit two transactions, a claim and a proof. Since each of these transactions costs the hardcoded amount 0.01 POKT [2], the operator wallet incurs a fee of 0.02 POKT. If a servicer is staked in a non-custodial manner, relay rewards are distributed to three wallets, DAO, BlockProposer, and the servicer’s output address. Intriguingly, the operator address receives no rewards, even though a transaction fee of 0.02 POKT is debited from this wallet. As a result, node operators must regularly replenish the operator address of their non-custodial nodes.

We implemented a solution to this issue in this feature. With the introduction of delegators, the workflow is as follows: after the DAO and BlockProposer portions are deducted, the node first allocates the transaction fee cost to the operator address. It then distributes the delegators’ shares to their respective wallets and sends the remaining tokens to the output address. This means that relay rewards are now distributed across five types of wallets: the DAO, the BlockProposer, the servicer’s operator, the delegators, and the output address.

With the current RTTM, the relay rewards from a single evidence submission can be less than 0.02 POKT. Earning such a minuscule reward ultimately results in a net loss. To prevent it, we implemented a mechanism not to submit a claim transaction if the rewards from it are expected to be less than the reward cost. It’s “expected” because we cannot accurately calculate the amount when we claim it. The amount of the relay rewards is calculated when a node processes a proof transaction. It’s possible that RTTM or a servicer’s stake amount may be changed. Therefore, we put this part of change behind a new configuration so that a node operator can choose which logic is preferable.

This distribution to delegators is applied to block rewards too. Unlike relay rewards, there is no cost to earn block rewards.

Another topic we need to discuss is “editing”. The upgrade to RC-0.10.4 enabled the new feature Output Address Edit [3], which allows an MsgStake transaction signed by the current output address to change the output address to another. Now who should be able to change delegators? We propose that only the owner of the node operator should have the authority to make changes as follows:

  • OutputAddress:
    Only the current output address owner has the authority to modify. (since RC-0.10.4)
  • Delegators:
    Only the node operator address owner should have the authority to modify. (Our proposal)

You may think that this reinstates the security risk that relay rewards are now in the custody of the node operator because they can change the commission percentages to 100 so that zero rewards go to the output address. You’re right. With this model, node operators can change the percentages to any value any time. Nevertheless we think this is acceptable for the following reasons.

Node operators may want to increase/decrease the commission percentage for a legitimate reason.
If a node operator illegitimately appropriates rewards by tampering the percentages, customers still have the option to unstake nodes and reclaim their staked tokens immediately. And that would severely damage the reputation of the node operator, likely rendering them unable to continue in the business.
Compared to the staked amount, which is still in the custody of the output address owner, the amount of relay rewards is much smaller.

[1] PIP-9 Consensus Rule Change – RC-0.8.0
[2] https://github.com/pokt-network/pocket-core/blob/353dd1047a5621a6dbc8351b28196cd39f5e7445/x/pocketcore/types/fee.go#L4-L5
[3] PIP-30: Consensus Rule Change – RC-0.10.0

Dissenting Opinions

As discussed above, the proposed features enhance the Non-Custodial staking feature. We believe there is no downside in the ideas. If there is any opinions which disagree with this proposal, it could be the risk of regressions or upgrade operations, which should be addressed in testing.


  • 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 submit a tx.

$ export POKT=<path to pocket>
$ 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.

9/8: Made following inline edits:

  1. remove “instead of decreasing the value of pos/MaximumChains [3] which is proposed as GANDALF [4].”
  2. remove “[3] Protocol Parameters - Pocket Network” and “[4] Pre-proposal: GANDALF (Decrease MaximumChains)”
  3. there was a mistype in “five types of wallets: the DAO, the BlockProposer, the servicer’s operator, the delegators, and the operator address.” → s/the operator address/the output address/


  1. Added more details to implementation section.

Thanks for puttingup this work, v0 needs some attention…

Chain Multipliers

I think fees per chain and number of chains by node are two completely different subjects. We need per-chain RTTM but implementing it wont solve any of the problems that multiple chains by node creates. I would leave out the subject of chain incentives aside, the fact that archival nodes are more expensive than light nodes is more than enough justification for this change.

I believed that there was some unused parameter to address this, it is likely that I’m wrong, but I will ask.
Has the parameter auth/FeeMultipliers any relation to per chain fees? It is currently set to 1 but it could be a list containing different fees.


You propose to divide rewards to (correct me if wrong):

  • DAO : As usual.
  • BlockProposer: As usual.
  • Servicer Operator: Only claim/proof fees. This exists because the fee is not proportional to the claimed ammount, so the operator must always be refunded at least this amount.
  • Delegators: A list of addresses with percentages of the remaining rewards, I suppose that the sum of percentages is <= 100%
  • Operator Address ?? I think that this is the Output Address, maybe a typo? : This will receive the rest, its a way of saying “the owner of the node takes all that is not claimed for”.

I think I agree with this.
The “editing” of the delegators might come with some debate, but it seems fair and also the changes will be visible in-chain for everyone to audit and/or set alarms if the operator changes these parameters.

1 Like

Got a few questions:

You suggest that having a dynamic RTTM per chain would create chain balance instead of balancing the network by reducing MaxChains with GANDALF. The suggestion appears to be that inflating chains rewards, regardless of how many nodes are on it, would be better than balancing out the network by lowing the MaxChains.

Below is showing from GANDALF how imbalanced chains are…

Using the chains shown above…

  1. Could you map out how decisions would be made to change the RTTM per chain?
  2. How would you set the RTTM per chain?
  3. What data would be used to define the RTTM for each chain?
  4. How often would they be updated to try and balance out the network?

I could see us doing dynamic RTTM per chain, AFTER the network is incentives for balance by reducing MaxChains. Then most chains would be in a more natural balance and you can set dynamic RTTM from a place of balance. Your suggesting that balance can be achieved simply by manually pulling the levers on every chain which I do not see.

Thanks in advance :+1:

1 Like

Thanks for the comments.

Could you map out how decisions would be made to change the RTTM per chain?
– Existing chains: DAO can decide what they are worth with feedback from node operators and portal operators. We can quickly adjust archival node rewards, making them more fair, therefore more feasible to run.
– New chains: Chain proposers should decide how much they want to charge. They will most likely talk with portal operators to get feedback (too high price will preclude sales at the portal, so regardless of what they want to charge, they won’t get any relays). Other chain allow-listing considerations remain.
– Non-standard rewards for both existing and new chains should be non-inflationary (or, at least, not more inflationary than regular chains), meaning, portals burn as many tokens as minted (vs. today’s basic per-relay fee, which will be of course completely out of line for those more complex, therefore more costly chains).

How would you set the RTTM per chain?
– It is a parameter change, so handled like any other parameter change.

What data would be used to define the RTTM for each chain?
– I think this question is almost the same as the first question. We define RTTM based on feedback, chain proposer’s demand, etc.

How often would they be updated to try and balance out the network?
– Up for debate. Every month?

1 Like

Thanks for the detail, but this would be impossible for the DAO :sweat_smile: A lot of time and discussion went into the network-wide RTTM… and your scenario, now the DAO would have to decide on the RTTM of each individual chain?

This would mean that providers could focus heavily on a chain, then try to petition the DAO to increase the rewards of their chains, which would increase their market value, and reduce the value of other providers on other chains. What you are not communicating is that by increasing the weight of one chain, it will decrease the weight of other chains (because the network RTTM is still only mints a set amount of POKT). This means that any changes would effect the rewards on every other chain on the entire network. Each change would effect benefit some provider and hurt others… and the DAO is suppose to decide all of this.

The DAO can not be in the place of deciding the balance of 50+ chains. The level of work that would have to go into every provider arguing why their chains should get more rewards, or why other chains shouldn’t get more reward, it an impossible place for a DAO to be.

The only solution is to first balance the network, and I’ve objectively proven that MaxChains is why we have some much imbalance with little economical effect. I’ve proposed that we fit the issue at the source, however this proposal doesn’t fix the core issue, but insteads tries to artifically balance the network through bureaucracy. While I don’t believe that was your intention, that is how this plays out.

This put the DAO in a place of deciding who has the advantage against another, because any vote to change a chain is an action against any provider on that chain. The amount of infighting will be insane.

I don’t disagree with RTTM per chain, especially for archivals and such… but there HAS to first be natural network incentives for balance (which is why I did the GANDALF research in the first place). This proposal would be a classic cart before the horse situation.

1 Like

Thank you for your comments and support!

I think fees per chain and number of chains by node are two completely different subjects. We need per-chain RTTM but implementing it wont solve any of the problems that multiple chains by node creates. I would leave out the subject of chain incentives aside, the fact that archival nodes are more expensive than light nodes is more than enough justification for this change.

Sounds fair enough. We will leave out this part.

I believed that there was some unused parameter to address this, it is likely that I’m wrong, but I will ask. Has the parameter auth/FeeMultipliers any relation to per chain fees? It is currently set to 1 but it could be a list containing different fees.

Thank you for bringing this up. I didn’t know auth/FeeMultipliers.
You’re right. The parameter does exist and defines multpliers for transactions fees per message type e.g. 2 for MsgClaim, 3 for MsgSend, etc.

It’s totally doable to put per-chain RTTMs in this parameter because both message types and chain IDs are strings anyway, and it reduces the patch size, but using the single parameter for two purposes is confusing. I prefer to introduce a new parameter.

Operator Address ?? I think that this is the Output Address, maybe a typo? : This will receive the rest, its a way of saying “the owner of the node takes all that is not claimed for”.

Sorry about that. Yes, it was simply our mistype. We will update the post.

1 Like

Great to see input being put in to better align work to rewards.

I think @shane brings up a good point that the mechanics will have to be worked out and largely set/automated, otherwise the DAO time commitments and infighting are going to be unworkable.

However, I do think this is possible to achieve.

  • Set base multipliers for Archival, Trace call Chain IDs (or alternatively, agree on min-max bucket multipliers that each Chain ID can receive).
  • Set min-max multipliers for other instances of needing increased rewards to incentivize outcomes- new chain participation etc.
  • debate a set of rules of how within these buckets the exact multiplier is set- i.e. standard deviations away from the optimal node count can be set to auto-increase the multiplier.
  • recognise that this is all as a % of 100. So as each new Chain is added to the network, all other Chains auto-reduce their % of total rewards.

My initial thinking is this is possible and positive, but the devil will be in the details. We’ll need to automate everything, or we certainly won’t be in Jack’s Christmas card list if he has to manually set 50+ Chain RTTMs.

I’m curious how you think this would work. Below is a screenshot from GANDALF showing what ETH Archival Tracing (0028) was making when I released GANDALF. Not much has changed to what it is today (I just checked).

In a balanced network, there would be 2,589 servers on 0028 and they would be generating .31 POKT per day (with MaxChains at 15 like today). However, 0028 is overstaked at 6,062 servicers (which is 3,473 than it should have), which means the average reward per servicer is .13 POKT.

Should 0028 get increased rewards when it overstaked at 234% (when it should be 100%)? Because 0028 typically has heavier calls, how much more should the rewards be increased to account for their heavy calls?

How About Double

How about double 0028 rewards? If rewards are doubled, then 0028 would generate .26 POKT instead of .13 POKT. We are talking about less than $.08c worth of value a month by “doubling” 0028 rewards. How is that at all worth the DAO’s time and effort, especially since 0028 could be making a whopping .31 POKT per day if c0d3r wasn’t staking over 4k of their nodes on 0028, making it over-provisioned in the first place.

You see how it would be impossible to even work out the rewards for an archival chain like 0028? c0d3r wants to increase the rewards for 0028 because the calls are heavier, which today would benefit c0d3r (despite c0d3r already over staking on 0028), while a provider like POKTScan, who is not over provisioning 0028, would see their rewards across all their chains reduced to pay c0d3r more for the archival they are over-provisioning.

Balance First

Again, what is going through all this worth if the effect is less than $.08c a month? If we first fix MaxChains, then we could talk about archival RTTMs, because then a provider like c0d3r would be heavily incentivized to NOT overstake on a chain like 0028.

If MaxChains was set to 3 and c0d3r was contributing to overstaking on 0028, each of their nodes on 0028 would be making -2.68 POKT per day. That is substantial reason to move to another chain, instead of overstaking.

In reality, because 0028 has such few relays, then most likely small providers would take over 0028 and large providers like c0d3r would focus elsewhere. By trying to do RTTM per chain would only create MORE imbalances, because a provider like c0d3r would be rewarded overstaking, while a provider like POKTScan would have their rewards reduced.

You have to balance the network with GANDALF before doing anything else with chain rewards.

P.S. I’m not suggesting that c0d3r is submitting this proposal to unfairly increase their rewards, I’m just point out the reality of what would happen with 0028, as it was an example given. Only love on this end @bulutcambazi :slightly_smiling_face:


Once the feature ships, we don’t need to change anything. It brings the flexibility but doesn’t require any action. However, I’d recommend:
– Don’t change anything for any of the existing full-node chains. They remain at base 1x multiplier.
– Set 2x multiplier for Archival and Archival Trace nodes. They are indeed at least 2x more costly to run.
– New chains are discussed as they come. RTTM will just be a new part of the proposal.

recognise that this is all as a % of 100.

I understand why you say that. But I disagree with this. I think any chain that is not base multiplier (i.e. 1x) should not be more inflationary than 1x chains. If it costs more to node operators to run those nodes, and if it cost the network more in terms of tokens minted, they should also cost more for portal operators to serve them. Otherwise, it would be unfair.

Please don’t consider the motivation of RTTM change just to be fairer to archival / trace nodes. The real motivation is enabling LLM and other generative AI scenarios. So, a new chain should not get allow-listed at the cost of other chains. This is not a zero sum game, or a limited pie to be shared. We are hoping to expand the pie.

Each relay is 100x to 1000x more costly for a node runner to serve. They should be properly rewarded to be able to serve them. And each relay is also much more valuable than a simple blockchain RPC relay. So, the demand side should pay accordingly.


Shane, I’d keep what GANDALF wants to achieve separate from this proposal. This proposal is about:

  • The principle: Equal rewards for equal value. If a chain brings a larger value, it should be rewarded as such (and also should cost as such at the demand side in terms of burns). Can we agree that equal pay for equal work by itself this is a good and fair thing to have?
    • Incidentally, this helps your cause, too. One of the motivations of GANDALF is supporting the little guy, right? With the right per-chain incentives, the little guy can afford such expensive chains more easily with or without GANDALF. (Which is not a problem for a larger node runner, because they can more easily use economies of scale by spreading the cost)
  • The strategic move: Unleash what POKT can do. Today, pretty much the maximum complexity that POKT can run is archival trace nodes. At current inflation rate and current POKT price, anything beyond that doesn’t make much economic sense. If Pocket ever wants to do more than serving blockchain RPC, it will need higher rewards to compensate the higher costs.
  • The tactical move: We will have a new tool for the demand side and allow-listing some new chains. Imagine there is ABC coin, and they want to be supported by Pocket. Now, they could commit 10M POKT to be burned, and hence, set the rewards at 5X multiplier for as long as their commitment lasts. This can become very handy for new chains that are currently in development but will become online as the bull market approaches.
1 Like

Re Feature 2, I think this can be a useful v0 addition (as opposed to queuing up to add in v1), as this solves a fairly prominent point point re non-custodial. If discussions prove this feature to be less controversial than feature 1, as a v0 consensus-breaking change, you may wish to break this into two separate proposals and give the community the chance to decide on the features separate from each other. (Of course, if both features are approved, they can be developed in tandem into a single build).

Re Feature 1, following are some thoughts in no particular order.

-I agree that per-chain RTTM and GANDALF are separable issues. Whether or not it may be in the best interest of Pocket Netork to reduce MaxChains has no bearing on the utility of per-chain RTTM (addressing this comment more to @shane than the present authors)

-While per-chain RTTM is a utility that I think POKT needs, I am not convinced the utility is needed in v0, Why not wait until v1, where it an be added as part of a holistic approach to mint and burn? By holistic approach, I mean, in addition to differentiated handling of chains, also the differentiated handling of geozone (some geozones are more expensive to operate in than others) and call type (some calls are more expensive to service than others)

-In your replies you allude to the need to adjust fees on the demand side in tandem with adjusting RRTM multiplier. This is the correct approach. However, there is nothing in the proposal that i can see that addresses this aspect. This is another reason I lean toward waiting until v1 where the demand and supply side can be worked out synergistically. Per chain RTTM implies per chain burn once burn turns on if we want to keep mint bounded, as your comments imply.

-Re auth/FeeMultipliers : I think multipliers for transacion fees per message type are completely orthogonal to the discussion at hand and not useful as a vehicle to accomplish your purposes (e.g., 0.01 POKT for one message type vs 0.02 for another message type)

Re @cryptocorn comment “recognize that this is all as a % of 100.” - I suggest you go back and re-engage this point; i was not satisfied by your response. We have a long way to go before mint< burn; for the time being they are fairly decoupled and from a system management point of view, it makes sense to have a target system-average RTTM and a multiplier across chains than ~averages to 1. That being said, from the point of view of maturity where mint is all “paid for” by clients via burn, I understand your response. Note that it is app burn (whether self-stake being burned or portal stake being burned which in turn is billed to portal clients), that is the ultimate balancer to mint. The current Gateway fee is just a precursor to this eventual protocol-level fee collection mechanism.

-Apart from the discussion of implement in v0 or wait until v1, I see no reason that approving and implementing the code change to allow per-chain RTTM is dependent on first coming up with the best way to determine parameter values. There is precedence for approving a code change first and deferring the mechanism used to alter parameter values away from a default set.

-That being said, I foresee there possibly arising a dynamic pricing feedback mechanism… too little coverage of a chain (or geozone - see previous comment) feeds into increasing the RTTM on a chain; whereas being overprovisioned feeds into decreasing the RTTM on a chain. This can be automated so that there is very little manual work needed to set values.


If we are talking about rewards per chain, then we have to talk about rewards per chain as a whole. Trying to limit the conversation about rewards per chain to only talking about RTTMs and ignoring MaxChains is like trying to fix a broken engine with new tires.

Farther down in your comment, you again say :point_down:

Again, you believe that this is a means to achieve proper incentive per chain “without GANDALF”. Clearly GANDALF is related, and this is being suggested as an alternative, so trying to separate them is impossible.

I don’t disagree with the per chain RTTM concept and have supported it in the past. The issue is you are trying to introduce it into a system that is rigged to only benefit the larger providers. It akin to trying establish “equality” into a system that at it’s foundation is rigged for those with infrastructure power.

Seeing that the principle of equality is part of your motives here, then I invite you to first join in fixing a more foundational root issue that has crushed the little guy, which is MaxChains. Instead of the DAO figuring out the “right per-chain incentive”, we de-rig the system from requiring someone to run 15 chains to get network average. Make it so anyone with a chain node can participate in POKT, instead of requiring them run 14 other chains as well. It is a no-brainer for those who want little guys to re-join the POKT ecosystem.

You are mistaken in believing that RTTM per chain will have meaningful impact on the little guy. If we look at the data today, by doubling archival chains, as you have suggested, for a chain like BSCA it would generate a whopping $.26c more per month for each of the 745 servicers. This means that someone is supposed to run a BSCA for $.52c per month. This means that BSCA as a whole generates $391.87 which is spread across a few node runners.

According to the numbers though, larger enterprises like yourself would benefit the most. By doubling ETH Archival Tracing it would go from $482.75 to $965.50, and since c0d3r has the majority of ETH Archival Tracing, most of that $482.75 would go to you. Those with larger amount amounts of node, like yourself, would objectively benefit the most… so it is a misunderstanding to suggest it benefits the little guys.

Benefit The Little Guy

Instead of increasing the rewards for archival chains by a few cents each month, reducing MaxChains would reduce the cost of infrastructure for small node runners by hundreds or thousands of dollars.

Example: Take a node runner with 10 POKT nodes. What would be better?

  1. Increasing the monthly reward for BSCA from $.26c to $.52c per month (while still requiring them to run 14 other chains)
  2. Allow them to generate full rewards on 1 chain, and save $100s by shutting down infra for 14 chains.

Objectively #2 is better. If you were to first Reduce MaxChains to 1, then double rewards with dynamic RTTM, and the reward bump would be more meaninful $11.50 to $23.

When it comes to the principle of meaningfully bring equality to node running, everything objectively first starts with MaxChains.

Again, I agree with the notion, but we are again trying to put the cart before the horse. You want to start preparing POKT for “more than serving blockchain RPC”, but that can’t happen until there is balance. You mention using POKT for AI API calls… that is awesome, but someone running the AI would also have to run 14 chain nodes. Nothing makes sense until someone can participate in POKT with 1 data source.

Yes, let’s prepare for AI API, by making it possible to run 1 data source per node (not 15), then we can balance out the rewards per source. I would be happy to work with you to make this happen.

I don’t agree this is the best tatical move. If you want to add new chains, and enable chain adoption, then the best thing to do would be to allow the ABC chain community to join POKT and generate meaningful rewards by serving only ABC requests on POKT. The way you are looking at creates incentive for existing providers, like yourself, to run unprofitable chains. In reality though, for a new chain like ABC, there are likely folks in that community that already run ABC nodes and would join POKT to further monetize their existing nodes.

When we first started adding new chains, this marketing strategy worked. POKT had multiple marketing opportunities directly with foundations (like AVAX and BSC) to promote their chain launch on POKT and encouraging their community to monetize their nodes on POKT. It worked in the past and could easily work again for new chain if POKT was back to being a way for anyone to generate meaningful rewards from a SINGLE data source.

Etherum’s mining wasn’t structured so that you had to have 15 video cards to generate average rewards per hash power… you just needed 1. POKT is fundamentally backwards from every other project in crypto.

The system is currently rigged so that only those with the infra to support 15 chains can generate network average rewards. Trying to address these issues with per chain RTTM doesn’t address any core problems, but instead makes it so that those with the most influence over the DAO would benefit the most from per chain weighting. You still have not addressed how this would NOT lead to bureaucracy mayhem.

1 Like

Thanks for the response, I agree that using the auth/FeeMultipliers for two purposes would be confusing. Thanks for clarifying.

Just to confirm, is this correct?

I’m specially curious about the delegators, any address can be assigned as a delegator?

I think that this is the real deal, could you share if you have some development on this subject?
While IA-related RPCs are not much different than blockchain RPCs, there are many important details around them.

The Balance

@shane @Cryptocorn and everyone else feeding into the subject of balancing.
I don’t believe that it is important to discuss here. This patch introduces tools that are needed, but it does not introduce any parameter change. This means that before and after implementing this change the rewards per chain will remain exactly the same. We can then start discussions on a per-chain basis and vote on the changes, on other threads.

The balance that you want to achieve is not feasible by the PNF, it must be automated. Also, it should (and can) be agnostic of the number of chains per node. We have developed such a method, based on the entropy of the staked nodes by chain, you can read about it in this thread (V1 fairness). The method does exactly that, modifies the RTTMs based on the staked nodes per chain, I encourage you to discuss the automated balancing there.

I’m not trying to censor the discussion, but it is completely irrelevant to this patch IMO. We should keep this clean and discuss the functionalities that are being proposed, not the effects of using them in a way or an other.


You see value in creating the tool, even if there isn’t a plan on how to use it yet. I don’t agree with that approach.

If you are going to create a tool, then it needs to already have a path to usage. Without laying out how this tool will be used, then it… :point_down:

I also don’t believe this tool is needed in v0 unless it has a plan for using it. I think everyone agrees to having this kind of functionality in v1… the v0 argument hasn’t been made. Unless we are going to be unleashing AI APIs before v1, then I don’t why it should be a v0 priority, when there are other more pressing v0 priorities.

If the goal really is to build this tool in v0 (which I’ve heard will come with a development cost) and not have a plan for how it will be used… that makes no sense to me… especially when there is concerns on how the usage will look. I’ve made clear arguments about why I don’t believe it will have the intended effects, and these effects are the motive to building the tool in the first place.

I believe we may just see this differently.

1 Like

Re “Balance”, I agree with @RawthiL that the mechanics of how to accomplish balance can be worked out in another thread, and in particular the v1 Fairness thread alluded to. However, I would think that hashing out the implications of this proposal (coupled with a PUP setting non-default values) on aggregate mint rate, inflation, potential reduction of rewards on some chains while raising rewards on others, etc. does belong squarely with this proposal.

The community has gone out on a huge limb to slash provider rewards to a level such that POKT can claim sub 5% inflation. Taking action that can muddy the waters of this narrative that everyone has made sacrifices to achieve may not be the most prudent. This is what I fear would happen if we were to pass this proposal in tandem with any mapping that does not ensure no increase of aggregate mint, On the other hand, a mapping that does ensure no growth in aggregate mint will, in most cases, come at the expense of decrease of mint on main chains, which is a hard pill to swallow for node runners not focused on archive or specialty chains

IMO: Regarding use cases involving archival chains etc that may call for/benefit from a ~2x bump in RTTM compared to system average, simply is not worth pursuing in v0, but absolutely should be part of the v1 plan.

That leaves LLMs. This is an exciting area to pursue. If there is bona fide opportunity to capture real revenue-generating business in this arena in the pre-v1 time period, then I absolutely think this proposal to enable 10x or 100x or whatever rewards needed to entice node runners to support such chains should go forward. BUT… it should presented in collaboration of at least one v0 Gateway provider who will sign on to collecting sufficient revenue and sending sufficient POKT per relay to PNF for burning for such chains so as to fully pay for the service (or at a minimum have a mint/burn gap that is no wider that that of other chains since we are still in a subsidy period). This solves the “balance” problem allowing aggregate mint to remain bounded to <5% inflation while not decreasing the rewards on other chains.

1 Like

I think that this is the real deal, could you share if you have some development on this subject?
While IA-related RPCs are not much different than blockchain RPCs, there are many important details around them.

Glad you asked @RawthiL ! Take a look here: Llama Demo over Pocket
This is an LLM implementation that runs on Pocket Network (private testnet) end to end. Imagine we can have this in Pocket Network in just a few weeks. This type of gen-AI queries take up to 15 seconds (even on a high-power GPU machine), hence they cost WAY more. If we want to enable such advanced scenarios, we need to be flexible with how we reward the nodes running them so they can be feasible.

Also I want to remind that actually bringing up these scenarios take time, I would love to be ready in time for when v1 ships?

That being said, I foresee there possibly arising a dynamic pricing feedback mechanism… too little coverage of a chain (or geozone - see previous comment) feeds into increasing the RTTM on a chain; whereas being overprovisioned feeds into decreasing the RTTM on a chain. This can be automated so that there is very little manual work needed to set values.

This is an interesting idea @msa6867 and could be a way to achieve what Gandalf wants to achieve in a different way. But there would still need a way to account for fundamentally different cost (sometimes 1000x) of running chains. In any case, success of one chain should not come at expense of another chain. New chains don’t share a pie, they grow the pie!

The issue is you are trying to introduce it into a system that is rigged to only benefit the larger providers.

@shane I don’t share your adversarial view.

  • It is not rigged, larger node runners are a necessity of current economic climate. On average, a 60k node makes barely $8 dollars a month. Even if the gateways were free, $8 wouldn’t pay the electricity bill of the computer it runs on (0.4kW x 24hrs x 30 days x $0.12 = $35) You need a large number of them to make your while worth. At which point, you need at least part time human attention to take care of them, so they are healthy and performant. And let’s not forget, performant gateways (needed for cherry picker) are many times more costly than your pocket node. At which point, you are not the little guy anymore.
  • This proposal wouldn’t benefit only the large node runners. In fact the opposite: A single person could be running a very sophisticated (and highly rewarding) chain, and be profitable, if we allow such chains. Imagine it would be possible to make 10000 pokt per day on a single machine, because what it offers is so valuable. New type of more agile node runners could show up, instead of running old-school chains, they disrupt the big guys with innovative chains.
  • This doesn’t further unbalance chains. On average, Eth Archival Trace makes 0.066 POKT per day. That is $0.0495 per month. 5… cents… per… month… before rewards share! Doubling it is not a decision maker for any node runner. You know what is a decision maker these days, when most node runners are barely (if at all) profitable? Cost. Node runners are overprovisioned in some chains because they simply cannot afford even more chains (both in hardware costs and personnel costs) so that they are better balanced. So, I am not proposing this so large node runners can nefariously make a few more cents per month per node.
  • If Gandalf passes, and all the chains are balanced, they will all have the same revenue, so everyone will want to run the cheapest chains. Don’t you want to give any incentive for unlucky ones running some of those more expensive chains for the same balanced overall rewards?

This proposal is about enabling some new scenarios, and to give some new tools to both supply side and demand side. It is not about balancing (although it can help), and it can live in harmony if they both were to pass. So, can we please take Gandalf to its own post?

Regarding the “bureaucracy mayhem”. I don’t see it. A cost factor will be a part of a chain proposal, and the onus will be on the proposers to justify any deviation from today’s defaults. It is not like we have exciting chain event every day anyways. What happens for existing chains can also be a one-time vote.

1 Like

Your first mentioned this proposal being for the little guys. They do exists and there are still some folks that run POKT nodes from their homes, mostly using Node Pilot, though typically well below network average. GANDALF starts making the network conducive to such node setups, and this proposal was presented as a way to help out them out as well… hence why I took time to reason out how that would not be the case.

GANDALF is stalled at the moment because it either takes gateways to change their cherry picker parameters to check how many chains a node is staked with, or it takes network upgrade change where the network checks if the number of chains a node is staked on equals the allowed value before the node is put in a session.

So far PNI and PNF have been absent from the conversation, so there isn’t a clear path forward. Honestly, if you wanted to add MaxChains checking to sessions as part of this proposal, so that MaxChains can be adjusted, then support would make more sense, as it would actually touch on much of POKT economic needs IMO. We would start fixing the actual economic engine of POKT.

That 10,000 POKT going to a single machine is coming out of the 220k being minted per day via ARR. So by having a single machine generating 4.5% of POKT’s total daily reward (which is $2,880 a month), the rewards on all the other RelayChainIDs get dramatically reduced.

Those without the hardware for LLMs (and 14 other chains) see their rewards dramatically reduced, while the LLM providers generate huge portion of POKT total rewards. Example :point_down:

This Proposal + POKT LLM

Lets say this proposal passes, and POKT LLM is launched given a 150x RTTM weight since it’s calls are 150x more resources (15s/.1s).

If this POKT LLM gets a low 2M relays a day, since it has a 150x weight, it actually has the effect of 300M relays being added to the network.

If 300M equivalent relays were added to the network via POKT LLM, then every other RelayChainID’s reward would be reduced by 20%. This is because ARR only allows 220k POKT to be minted per day, so POKT LLM would take 20% of that mint due to it’s weight.

This means that everyone who does not have the infra to support POKT LLM would immediately have their rewards cut by 20% immediately. Only those with the hardware chops to support POKT LLM will get the $40k being produced each month.

This 20% shift of the rewards to LLM providers, would only create $1.7 a day in protocol burn revenue (GatewayFeePerRelay). Is $255 of monthly burn worth shifting $40k of rewards to those with LLM capabilities? I’m not sure… as technically POKT LLM should be generating $7,650 if it’s GatewayFeePerRelay was properly weighted.

To make the whole network benefit from POKT LLM, from my perspective, there would need to be a dynamic GatewayFeePerRelay per RelayChainID to be a part of this proposal. The more folks that use the more expensive POKT LLM, the more POKT is minted, without compromising POKT’s desire to be low inflation and eventually deflationary. I already modeled out an ARR that is not a flat 220k per day, but connected to what is being burned, so technically most of the economic work for this is already done in Burn And 🥩 Harnessing (BASH) Deflation Economic Model.


I can’t say this enough, I support this kind of move. Not entirely sure if it works for v0, but I’m more than willing to consider it… so thank-you for bringing this forward.

To actually make POKT v0 conducive to this kind of fundamental change, then I see this proposal getting us 33% of the way there in it’s current form. To make this move towards serving POKT LLM, in a manner that does NOT further gut rewards for those without LLM hardware, and produces fair protocol revenue (burn), then personally believe this proposal needs to address:

  1. MaxChains fix (balance the network without the need for complex DAO levers)
  2. Dynamic GatewayFeePerRelay per chain (so the protocol can charge LLM RelayChainIDs fairly)
  3. Accompanying replacement to ARR to account for chain specific GatewayFeePerRelay per chain (as mentioned before, I’ve already modeled out an ARR alternative that connects inflation to the burn rate, so I would consider this already done).

To launch this in v1 makes TONs of sense because most of this is already being planned or can be incorporated… but open to v0 if it makes sense (hence why I’m putting time into flushing this out).

Not trying to be adversarial, just being pragmatic with the economic effects of such a move and the wider ramifications :sweat_smile:

Thank-you for all your response :slightly_smiling_face:

What are the hardware requirements for this? What kind of GPU’s would this require? This could be a very cool way to get old miners (like myself) putting GPU’s to use… so more info on all would be required of folks to join POKT LLM would be super helpful with all this decision making.

Big fan of the work overall :slightly_smiling_face:

1 Like

Thanks for taking the time and sharing your thoughts.

  1. MaxChains fix (balance the network without the need for complex DAO levers)

MaxChains is orthogonal to what we discuss. This proposal is not related to Gandalf. If/when Gandalf passes, we’ll be happy to help designing and making the changes. Until then, let’s keep them separate please.

… then every other RelayChainID’s reward would be reduced by 20%
2. Dynamic GatewayFeePerRelay per chain (so the protocol can charge LLM RelayChainIDs fairly)

We want to grow the pie, not to find new ways to share it, and in particular, we have no intention to make anyone’s piece smaller. Therefore, the intention is NOT to get the rewards at the expense of any other current chains. I think #2 is a good idea, and we can certainly do it in the scope of this project. My assumption, perhaps wrongly, was doing it off the chain. But I think you are right, it is indeed better to do it on the chain.

  1. Accompanying replacement to ARR to account for chain specific GatewayFeePerRelay per chain (as mentioned before, I’ve already modeled out an ARR alternative that connects inflation to the burn rate, so I would consider this already done).

ARR limits inflation, not the total volume. So, the good news is that it won’t need to change at all. Any adjustment to RTTM will simply need to specify a convincing GatewayFeePerRelay as well.

1 Like

If the focus for this proposal is focused around trying to support novel RelayChainIDs, like the POKT LLM (which is what this conversation as shifted towards.), then GANDALF wouldn’t as directly apply. Use this proposal to balance rewards across current chains (which keeps being suggested) then we do need to consider the entire reward per chain economic system.


GatewayFeePerRelay is currently off-chain, and was universally set by ARR. It may not need to be on-chain, but it would need to be in ARR (with a method/system to adjust) or in an ARR replacement.

1 Like

I think that if this is implemented and a chain RTTM is changes, then the GFPR for that chain should be changed proportionally. The DAO should not help the gateways operations by charging 1x for a chain that is paid x5. I think that this is not an issue as it can be simple resolved by setting up an increased burn to the increased mint.

Regarding LLMs (or any new chain for what it matters), the process is the same, set-up the chain, vote on the new chain price (if needed), set GFPR according, and that’s it. The only different from current whitelisting of chains, is that a price should be agreed on (if needed).

And this is why this matters. There is A LOT to discuss around this, but without this upgrade we cannot move forward into thinking about this.

I think that we are over-thinking a simple a needed change, other protocols (like LAVA) already have a pre-chain multiplier. It is not a wild idea, the subject of setting different prices per chain have been discussed multiple times. Now that we have a PR that give us this feature we should be focused reviewing that, making sure it is safe and it runs on the test net. All the discussions of probable scenarios that can arise due to having this feature is not pertinent to the feature itself. We can just decide that this PR is applied without changing anything (all RTTMs are the same) and then sit down and discuss.