PIP-6: Settlers of New Chains



Based on the feedback provided on previous proposals, we’re proposing a new method of bootstrapping chains by providing a minimum level of relays (revenue) on each new RelayChainID that will attract a minimum viable number of nodes while new RelayChainIDs are in their infancy. This would be accomplished by signaling the intention to whitelist a new RelayChainID and creating temporary, Pocket Network Foundation staked applications that produce on-chain rewards encouraging node runners to participate through predictable rewards. This technique effectively balances the needs for incentives and the inflation cost to users.

We would like to get feedback from the node community about how you feel with the timeline, proposed incentives and the chains the market is signaling us to support.


Whitelisting new chains in the SupportedBlockchains parameter is a complex chicken-and-egg problem, because whitelisting the chain for rewards before it is adopted by a significant number of nodes/apps leaves the ChainID vulnerable to targeted servicing, wherein apps can unfairly favor specific nodes when choosing who to send relays to, but without incentives we would struggle to bootstrap the two-sided market.

Incentive Bootstrapping Process

We have explored a few solutions to this problem but none were intuitive enough to take off.

  • CampaignNet: Initially, the plan was to run “CampaignNet”s, which would essentially be isolated incentivized testnets run exclusively for specific RelayChainIDs. However, this introduces another operational challenge of bootstrapping entirely new chains. This is assumed to be our solution in How to Whitelist New RelayChainIDs.
  • Centrally-administered Funding Program: We have also contemplated running a centrally-administered incentive program funded by the DAO and administered by the Foundation. Node performance would be recorded through the Pocket Gateway, which most apps use to connect to the network, and rewards would be manually distributed in a manner similar to the protocol’s automated block rewards. However, this also introduces an operational burden and would deplete the DAO’s treasury over time. It was deemed unsustainable from a time and cost perspective.

Governance of the SupportedBlockchains Parameter (Block Rewards Whitelist)

The governance process for whitelisting new RelayChainIDs is also imperfect in hindsight.

Currently new RelayChainIDs are to be whitelisted according to the following section in the Pocket DAO Constitution:

6.10. The SupportedBlockchains parameter will not be governed through voting, but instead according to the Network ID configuration choices of Voters. The Foundation will add Network IDs to the whitelist if 5% of Voters have configured their App or Node to include the Network ID. PUPs can still be submitted for this parameter to draw attention to new eligible Network IDs.

The hypothesis was that, since the Voters are proven non-sybils who have also been qualified as among the most knowledgeable in the community, they would make sensible decisions about which chains are worth whitelisting. It was also assumed that voters would probably represent a slice of the network as a whole, meaning if they support a RelayChainID the wider community of node runners probably does too.

However, this has two key problems:

  • Ineffective when the DAO is small: at the current count of 11 voters, 5% of voters is only 1 node runner.
  • Prevents voters from participating in incentive bootstrapping programs: the purpose of these programs is to help bootstrap the number of node runners, then whitelist a RelayChainID only once a certain threshold (resistant to targeted servicing) has been reached, but if any DAO voter participates in one of these programs before the threshold has been reached, they will satisfy the criteria to whitelist before the threshold has been reached.

Therefore, this proposal also aims to adopt a more sensible governance process for whitelisting new chains, which is also more compatible with the incentive bootstrapping process.


Previously, we have not adequately addressed ensuring that the whitelisting process is fair, transparent and reliable for all node runners who are currently staked, as demonstrated by concerns raised by node runners in response to PUP-5. We aim to resolve these concerns with the proposed incentive bootstrapping process.

We have also not given enough attention to how to embed testing and quality assurance into chain onboarding. This proposed process should allow us to test and debug any issues concerning the quality of requests in a controlled environment. This is an alternative to testing quality standards on new production users who are still on the fence about using the protocol which has demonstrated to be a contributing factor for churn.

This proposed process WILL:

  • Give node runners enough time to decide which chains they want to stake for
  • Provide fair playing field for nodes of all levels to join new chains
  • Guarantee an incentive for node runners to unstake and add new chains
  • Give the Pocket team a live testing environment for new chains to ensure smooth onboarding of new applications
  • Eliminate the demand/supply problem of onboarding new chains

This proposed process WILL NOT:

  • Impact existing incentives for node runners on existing blockchains
  • Initiate a new chain with no relays deployed on Day 1


Incentive Bootstrapping Process

  1. 30-days Notice: The Pocket Network Foundation will provide node runners with 30-days notice prior to incentive activation for a new RelayChainID, providing ample time for node runners to both unstake and spin up new nodes. This notice will include a mandate for a Minimum Node Threshold that will need to be met before the RelayChainID can be whitelisted in the SupportedBlockchains parameter.
  2. Unstaking & Restaking: Following this signal from the Foundation, node runners will be able to unstake and restake their nodes with a buffer of 9 days in addition to the 21-day unstaking period.
  3. Day 27 Node Count: 3 days prior to whitelisting the RelayChainID, the node stake count will be performed on the RelayChainID. If the Minimum Node Threshold hasn’t been met, the timeline will be extended to accommodate the entry of additional nodes.
  4. Whitelisting: If the Minimum Node Threshold is reached by the indicated date, the Foundation will activate the allotted chain.
  5. Relay Bootstrapping: Once the incentives are activated, the Foundation will provide a Baseline Relay Count, ensuring minimum viable revenue to node runners, while simultaneously load testing the new chain with a variety of relay types. This Baseline Relay Count will be whatever is needed to economically support the Minimum Node Threshold, including the cost of running the nodes as well as the opportunity cost of being unpaid while unstaking for 21 days. Since different chains have different costs associated with running nodes, this will vary from chain to chain. These relays sent by us would exist until we onboard new applications for these given RelayChainIDs and no longer need to subsidize nodes.
  6. Onboarding New Applications: Having a pre-existing network of nodes that has been load-tested will make it easier for us to onboard new applications. While our solutions team works on outreach, the developers of tools such as the Pocket Dashboard and Node Pilot will also be able to integrate the new chains natively.
  7. Ending Relay Bootstrapping: Once we have reached enough organic relays to match the Baseline Relay Count, we will stop submitting relays from the Foundation’s stake. If it becomes clear that the chain will not sustain an organic relay count to prevent targeted servicing, e.g. due to abandonment of the chain by applications, the DAO may vote to (blacklist) remove the RelayChainID from the SupportedBlockchains parameter.


Update 6.10 in the Constitution to:

6.10. RelayChainIDs will be added to the SupportedBlockchains parameter (whitelisted) by the Pocket Network Foundation according to the process outlined in ‘PIP-5: Settlers of New Chains’. The Foundation will give node operators 30-days notice prior to whitelisting new RelayChainIDs. If it becomes clear that the chain will not sustain an organic relay count to prevent targeted servicing, e.g. due to abandonment of the chain by applications, the DAO may vote to (blacklist) remove the RelayChainID from the SupportedBlockchains parameter.


Baseline Relay Count to Provide Minimum Viable Revenue to Nodes

Baseline Inflation

The minimum amount of relays is dependent on the cost of running the nodes, the expected rewards and the estimated amount of nodes needed to prevent self dealing. For example, if it costs conservatively $100/mo to run a standard full node on a cloud provider, and we want to guarantee that there are 200 Pocket Nodes serving a given full node, that’s a total of $20,000 in monthly costs (if not running multiple pocket nodes to one bitcoin node) that needs to be covered in POKT rewards. Using a $0.80 OTC price, that would need to be 25,000 POKT minted in total throughout the month, or 93,632.95 relays a day.

$20,000 / $0.80 = 25,000 POKT a month
28,571 / 0.0089 = 2,808,988.76 relays a month
2,808,988.76 / 30 = 93,632.95 relays a day

Costs to run a Bitcoin Node
Number of months 1
USD cost/month $100.00
Number of nodes 200
Cost to operate Node 20,000
Break Even Point to Cover Node Costs
OTC price/POKT $0.70
Number of POKT/month 28571.43
days/month 30
~relays/POKT 100
~relays per day 95,238.10

Instead of one single application stake, we would advocate having 10 application stakes to spread the sessions to avoid RNG of not being chosen to participate in sessions. This Baseline inflation would continue until we onboard applications for these given chains or the community decides it is no longer viable to continue supporting that RelayChainID.

Opportunity cost offset

Additionally, to cover the opportunity cost of switching over, if nodes are on average, earning 20 POKT a day and the aim is to have 200 Pocket nodes, that is about 4,000 POKT a day, or 84,000 POKT in earnings missed out by nodes over 21 days. This would be an additional ~400,000 relays a day totalling to 84,000 POKT minted over 21 days.

Opportunity cost to switching to a new Chain
POKT/day 20
# of Pocket Nodes 200
total POKT/day 4,000
# of days/period 21
POKT/period 84,000
~relays/POKT 100
~relays /period 8,400,000
~relays/day 400,000

We propose that this opportunity cost inflation happen just once, for a single chain for the initial group of nodes. This will give everyone ample time to unstake once, and set up their RelayChainIDs for the new chains ahead of time. Given enough time, as new node runners come in or others are staking their POKT for new RelayChainIDs, there is no need to continue the opportunity cost offset program.

Total Network inflation

Assuming 6 months of baseline inflation for 15 chains this would result in:

  • 2,571,426 POKT minted to service nodes
  • 28,892 POKT minted to block producers
  • 288,924 POKT minted to the DAO

With an additional 84,000 POKT for the opportunity cost offset proposed for Ethereum Archival Mainnet trace enabled.

For a total of 2,973,242 POKT minted over 6 months. At a supply of nearly 660M POKT, this would result in 0.4% inflation over 6 months.

Purpose of Gateway relays

The applications that provide the initial relays will be designed, built, and staked by the Foundation. Providing this baseline creates an important function for the entire protocol.

Today, nearly all relays come through the gateway. It allows us to perform critical quality assurance of the service balancing and debug any issues with a given service.

Using an average baseline of 100,000 relays per month, per chain (depending on the node network) marginally increases the current inflation while seeding a robust initial set of nodes profitably.

Dissenting Opinions

Altruistic spam relays

There has been, and always will be, the challenge of altruistic spam relays. This would be individuals using the Gateway’s free tier to send requests to the network for everyone’s benefit. Just like targeted servicing, the effectiveness of this on an individual level becomes muted the more nodes there are for a RelayChainID.

Monitoring the gateway applications for legitimate applications that have been built as opposed to fake applications just using the endpoint for these altruistic spam relays will help avoid this.

We should wait until 0.7.0 QoS is implemented

The 0.7.0 upgrade, slated for later this year will remove many of these risks, using on chain data to automatically remove any targeted servicing. I would argue that the market demand for these new chains is high enough that moving forward with this proposal would still be worth doing.

This might adversely affect the node counts with large node providers

In light of the concerns regarding the amount of nodes on the network, this may result in a significant increase of Pocket Nodes from larger node providers. The largest node providers need to be cognisant of how they manage this with their customers, and should be replacing 1 for 1 with the new RelayChainIDs they plan on supporting to avoid overloading the network with nodes unnecessarily.


To conclude, we propose to split up the order of RelayChainIDs based on market demand and urgency versus more speculative, yet potentially interesting RelayChainIDs. Feedback on timing of these for node runners is crucial, as we want to make sure you have time for syncing and connecting these new nodes to your existing infrastructure setups.

To give time for feedback, we propose to begin the initial 30 day timer for implementation on May 9th. This would mean that we will begin making the first chain paid on June 9th, with each one successive RelayChainID paid on the date indicated below.

Node runners would need to have staked for these RelayChainIDs ahead of time and have the full nodes available on the given dates.

Schedule for paid chains

Edit: We originally had estimated dates for whitelisting these chains but now we are planning to wait on the 0.6.3 release, which will allow us to move more quickly. Without a clear date for 0.6.3, it doesn’t make sense to estimate dates for individual RelayChainIDs.

0005 Fuse Network
0028 Ethereum Mainnet Archival Tracing (Opportunity cost chain)
0010 BSC Archival
0004 BSC
0003 Avalanche Mainnet
0027 POA xDai
0023 Ethereum Ropsten testnet
0025 Ethereum Rinkeby testnet
0026 Ethereum Goerli testnet
0024 Ethereum Kovan testnet
0006 Solana
0009 Polygon (Prev Matic)

More speculative, yet interesting RelayChainIDs:

0002 Bitcoin
0012 Optimism
0011 IPFS
0013 Filecoin
0014 Flow
0015 Arweave
0015 Algorand
0015 RSK
0007 Energy Web Token Mainnet
0008 Shyft Network Mainnet

We propose Ethereum Mainnet Archival with traces enabled to be the opportunity cost chain. As many solutions today need traces enabled for Ethereum, we would like to seed this network with as many Archival nodes as possible.

We propose a delayed daily activation of all supported chains using the forums as the source of truth.




Copyright and related rights waived via CC0.


Thanks for the detailed and thoughtful writeup.

Can you please share more specifics about what constitutes as “clear” in terms of unsustainability? Can this be defined as reaching X number of organic relays within Y days of whitelisting?

Am I right to assume that not all of these paid channels (from 6/9 to 8/11) will be incentivized? If so, what will determine whether they are incentivized or not?

Just how difficult is it to implement update stake command as part of RC 0.6.3? Or temporarily reduce unstake period parameter? That would

  • Remove the need to unstake/stake and opportunity cost measures.
  • Some of the larger node runners are already talking about unstaking their nodes and restaking them with these new chains. We may see massive unstake/restake events. And since unstake takes 21 days, any instability they may introduce cannot be easily reversed.
  • With no update stake command, node runners are incentivized to restake with as many of these new chains as possible to avoid further unstake/stake cycle. That will force them to stake for chains they may not be truly ready for.

Is the interest for updating stake command more or less represented by the arguments outlined here? Also, @bulutcambazi how imminently do you anticipate any unstaking? i.e. Do you think larger node runners will be mass unstaking 21 days ahead of the 1st dates for new chains?

Unstake and restake is logistically complex, time consuming and expensive in lost revenue and server cost. I’m unaware of anyone planning to mass unstake. I know a lot of people looking for clarity and guidance though.

Thanks for the feedback everyone.

I’m seeing a lot of support for editing stake before making any of these chains paid. I think that this is sensible.

Additionally, I’ve received some feedback about changing the MaxApplications parameter that would allow for significantly reduced risk with targeted servicing. This is also expected to be included in 6.3.

I’d opt to wait for 6.3 that includes edit stake and this MaxApplications change before moving forward with making any new chains paid.