PEP-33: Triforce Shard Income Proposal



Triforce offers Pocket Network an avenue to scale to 100 blockchains, while minimizing internal resource consumption in people and infrastructure by involving community members at the edges to take additional responsibility for shepherding the protocol more actively. Triforce shards are “Temporary Autonomous Zones” self-governed by the members of each shard (blockchain network) and managed in collaboration with community coordinators. Read more here.

This proposal seeks to incentivize Triforce shards with ongoing supplemental income tied to the success of the shard’s performance as measured by relays served per day. While shards may be serving free tier traffic initially, the expectation will be for shards to serve staked or otherwise paid traffic in the near future.

The incentivization is based on

  1. The growth of relays over time (on the specific chain that the Shard serves)
  2. The successful maintenance of the blockchain’s service
  3. The retention of relays that come through Pocket via Portal accounts, Public PRC endpoints, and SDK installs
  4. Ongoing Pocket Network brand awareness in the Shard chain ecosystem
  5. A reliable and consistent service as it pertains to chain service, issues, or questions

POKT is asking for 0.20% of total DAO rewards for the remainder of 2022 to be allocated as income for a maximum of 50 external Triforce shards. Shard Members will be paid out monthly in POKT based on daily relay performance, defined below. If deemed successful, a follow-up proposal will be submitted for the next tranche of shards. This proposal should be viewed as a pilot which expires at the end of 2022 or when 50 shards have successfully launched, whichever happens first. A new proposal would be required to fund this and future sets of shards in 2023 and beyond.

Each shard would be paid on a logarithmic scale that increases in pay till 5mn daily paid relays, and then starts to plateau out till the 50mn daily relay level. The charts below illustrate the relationship.

This model is designed to have rewards plateau at 50mn daily rewards per shard for a maximum of 2.5B total relays per day to safeguard the DAO treasury and inflation targets that PEP until V1 and Portal monetization enables us to revisit a long term model to sustain 100+ shards in perpetuity.


  1. To scale to 100 supported blockchain networks by the end of the year.
  2. Give community members and node service providers an opportunity to seize more responsibility.
  3. Minimize internal core team resource consumption, reduce centralization risk, increase external PocketDAO resource distribution.
  4. Provide income based incentives for community members to contribute to the growth of POKT network
  5. Compliment PEP-34. Shard Budget Proposal with on-going income incentives


Ongoing Budget: PEP-33: Triforce Shard Income Proposal

  • Shard member compensation is tied to performance as measured by relays served per day. Compensation per relay served is paid out in a logarithmic scale as outlined in the chart below.
    • Maximum 50 shards
    • Maximum 2.5B rewarded daily relays per day
    • Maximum Nominal POKT 7,063,868.73
  • This budget will be in place for Shards whitelisted in 2022 (including the 5 Shards that have been whitelisted this year prior to this proposal)
    • These 5 Shards being
      • DFKChain Mainnet
      • Fantom Mainet
      • Near Mainnet
      • Moonbeam Mainnet
      • Moonriver Mainnet
  • This budget will be reevaluated at the start of 2023
    • If no new proposal is put forth, this current proposal will remain intact
  • Of note: These rewards will not come from the 89% rewards share from Node Runners or the 1% rewards share from Validators.
    • These Shard Income rewards will come from the PocketDAO and will be supplemental income to contributor (additive to their normal Node Runner rewards)


Hypothetical Scenarios

Details Scenario #1 Scenario #2 Scenario #3 Scenario #4
Average Daily Relays 2.0M 12.0M 24.0M 50.0M
Daily POKT rewards given POKT 62.15 POKT 232.41 POKT 306.40 POKT 387.06
Annual Shard Income* POKT 22,684.75 POKT 84,829.35 POKT 111,834.62 POKT 141,277.37
  • shard income to be distributed across shard members as they determine

In the scenarios above, if 0.20% of total POKT minted for a specific chain is approved, this would create financial incentives for the Shard Members to perform their tasks, and for Pocket Network service to remain top-notch. Each scenario differs about how many relays that chain brings.

In short, if Shard Members are serving chains that bring in a couple of million of daily relays, they would get POKT rewards that would sustain their ongoing costs for service, but probably not as much as a full-time Web3 job would bring.

If Shard Members are serving chains that bring in tens of millions of daily relays, they would be handsomely rewarded and would be financially incentivized to keep service good and relay count high.

It is worth noting that TriForce members can also participate in multiple shards so they can accumulate these payouts based on how much they contribute.

Operational Considerations

  • Intention of the budget is to compensate individuals for value provided across shard functions: DevOps, Marketing and Business Development.
    • The default allocation for a Shard will be 0.20% of total chain POKT rewards divided between the 3 shard members.
    • This default can be changed (and is encouraged to be discussed) among the Shard members when they submit their application.
      • For example, if a Shard member feels strongly about their task, they can negotiate for 40% of the chain rewards while the remaining 60% would remain to be divided up by the remaining Shard members.
    • Any paid applications that are on-boarded via Triforce shards during the lifetime of this proposal will be subject to the same paid accountability measures as future shards, to be determined by a future proposal.
  • All compensation paid in POKT token
  • Shards will not receive incentives for relays beyond 50mm per day
  • Shards will invoice on monthly basis; invoices will be paid to a single account
  • Shards will be subject to the expectations listed here.


Upon passing of this proposal, the core team will begin the onboarding process for external parties to launch new chains and be compensated with associated relay growth. All external shards will be subject to the terms and conditions listed in documentation that will be hosted in the Triforce channel on Pocket Networks’ public server.

Dissenting Opinions

There is risk in treating shards as Temporary Autonomous Zones, and thus giving them autonomy over internal financials and operational management. What if internal conflict arises?

Each Shard will be led by a Shard organizer who is accountable for communicating or escalating any Shard changes or conflicts to PNI. The Program Manager will be available to act as a mediator as incidents escalate. Given the subjective reality of effort vs. impact from chain to chain, we believe it is better to give the Shards autonomy on day one to account for variables like organic growth, campaign pacing, and general chain interest.

Shards will not have sufficient resources to succeed without significant support from the core team

While there will be expectations for PNI to help launch and manage Shards, outsourcing communications, content creation, and standing up nodes to external teams of Shards enables us to launch chains in concurrency where we would have been limited to a few at a time. Additionally, as Community Coordinators are hired, opportunities to transfer ownership from PNI to Shards will be explored and implemented.

Furthermore, there is a separate proposal that addresses the upfront costs that a Shard may have with launching support. This proposal is for the ongoing financial incentivization that benefits the community and Shard members.

The overall POKT budget is too much

The DAO is capturing 10% of the overall protocol revenue. In the month of March, the Pocket DAO earned 8.66M POKT. This spend is worth it to reach the milestone of supporting 100 blockchain networks by the end of the year, especially if it liberates the Pocket Core team to focus on other high-leverage, strategic opportunities.

This proposal may seem like a budget ask, but it is directly tied to the growth of the network. When TriForce doles out these tokens, it is generating paid relays in parallel.

This is not enough/too much money for contributors as Shard members

Participation in TriForce is 100% voluntary and if an individual doesn’t find the income too low, another contributor might. Of note - this is additive income so this potential income is supplementary to current ecosystem participant’s income as a node runner or with their typical day job.

Conversely, if the income is too high, contributors would be incentivized to be competitive in submitting applications and providing better service than others to meet demand/meet service needs.

Furthermore, these amounts will be re-voted in 2023 when these proposal amounts expire. These currently proposed amounts could be separately voted on by an alternate proposal.


Copyright and related rights waived via CC0 1.


Thanks for this proposal. I was surprised to see that this went to vote without a single comment! so I’ll be the first :slight_smile:

Overall, I love the spirit and imitative to involve community members to help us scale, But Why are we so hyper-focused on 100 chains?

The largest concern I have about this proposal (or rather the goal) is that it’s under the assumption that we should be onboarding more chains. The biggest crisis we are dealing with right now is infrastructure costs for node running due to us prioritizing quantity over quality. This gives me the same vibes as our initial choice with Pocket nodes. If we onboard more and more chains, the infrastructure costs for the network continues to increase. We do not have an existing supporting mechanism to keep infrastructure cost down for chain nodes, yet we keep on-boarding more and more digging us a bigger hole to crawl out of. We need supporting mechanisms to actually utilize the chain nodes that are taking < 30% resources in a lot of node runners systems and a mechanism to drive customers to actually pay first before we scale out further IMO - otherwise we are back to same problem again and again.

There is absolutely no way this is feasible if every node runner decides to spin up their own chain nodes. That is how we spend a lot of money into resources and end up being over provisioned. It’s gotten us to where we need to be, but now it’s time to optimize and introduce more layers to make our network more efficient. I would feel more comfortable revisiting funding Triforce after we see a couple more things happen

TLDR - Bit neutral on this. Think it’s a solid idea, just not the right timing.

This is a good thought, but onboarding new chains will help expand the ecosystem and further expand the utility of POKT.

Infrastructure costs are not that high, they are high for certain organizations that pay cloud providers a premium + profit margin for running nodes. I think the focus should be placed on optimization(direct hires, thin client, bare metal, pruned chain, tuned caches …etc) into these organizations that heavily inflated the node count. They could have hired in house talent and built everything out on their own for at least a 75% decrease in node costs per day w/staffing paid for the year after running a month.

I think we should propose a chain sharing mech, with % rewards payout goes to the sharing node. If the Service node wants to support a certain chain but not necessarily run a full backend chain.


Node A wants to support Harmony(0040) but doesn’t want to stand up their own infrastructure yet until they sees how it performs in the market.

  • Node Runner B has Harmony(0040) staked and is offering stake_sharing to its peers , advertises this service to any node that connects as a peer. NodeRunner B would have to provide an additional parameter to the stake command : something like shared_chains which could be a dictionary indicating the chain ,to backend_ur mapping.

  • Node Runner B has staked shared_chains for certain chain_ids , allowing NRB to only share specific chains they have extra bandwidth, load …etc to handle and penalizing them if they do not have the actual bandwidth to support extra traffic(via cherry picker checks, other QoS measures.) Either directly via the cherrypicker or indirectly via the cherrypicker and the middleman Node A.

  • Node A has stake shared [‘0004’, ‘0005’] and regular stake [‘03DF’, ‘03CB’,‘0003’]
    Node A services relay for 0040 and there is a stake_split percentage for using Node Runner B’s Harmony as a relay chain; likely larger % split to Node Runner B for running and servicing the chain and the rest to Frontend relay provider Node A.

  • Node A will still receive full relay rewards for the chains they are regularly staked for, but when staked with chains in shared_stake the provider (Node Runner B). who is footing the bulk of the work for the shared_chains gets the larger percentage of those rewards (not entirely sure on the split).

This will allow for demand to scale with chain infra and allow smaller node runners experimentation with chains before they are able to build and service relays themselves. It will also allow chain_providers to utilize their idle-ish infrastructure and expand their backend availability for supplemental income.

Crypto is a fast paced moving entity, disregarding emerging technologies will not bode well.

POKTBlade edited his comment after I typed this, so I also agree with something along the lines of BenVans original proposal here: Incentivized decentralization - Idea - seeking discussion - #2 by Garandor

1 Like

In case you missed it in Discord, this proposal is up for voting Snapshot

Thanks for looking here @poktblade - obviously most of our attention is on node count and costs proposals so your diligence is greatly appreciated.

I can see the misunderstanding and concern. I think it is worth noting:

  1. TriForce payments apply to existing chains as well. ~90% of the infrastructure is already supported by the network and part of progressive decentralization is getting existing chains migrated to a working group format. You can be against the chain expansion strategy, and still vote for this to get current contributors paid.
  2. Even if we don’t do TriForce, Pocket will still probably get to 100 chains by the end of the year. Table stakes to stay remain a relevant product in this multi-chain world. Of course, not all node runners should support all chains due to economics and protocol constraints. And that is okay.
  3. The node efficiency is already being addressed elsewhere. This proposal is separate from those proposals and only applies to the calendar year. Fwiw - I agree that node optimization is paramount. However, there is no dependencies between the two work streams.

Again, @poktblade I largely agree with your concerns. I think the issue stems from how how Triforce was framed.


Fair enough, thought it was worthwhile calling out. This makes sense, thanks for the clarification

1 Like

Hey @poktblade thanks for getting the conversation rolling here :slight_smile:

I think that @RichCL covered a lot of great ground with his comment but I did want to add a clarification re:

This is not made explicit in this proposal but thought it might be worth making it transparent to the community that we are approaching the onboarding of Triforce shards/working groups in phases. Our growth goal for Triforce between now and September is modest (10-15 working groups/new chains) in an effort to align with portal monetization.

In addition to being mindful of network-wide economic concerns, this approach gives us the breathing room to iron out any operational considerations as well to ensure chain launches managed by working groups have the right resources, frameworks, and accountability measures to succeed. Such as…

I think the concept of shared infrastructure is awesome. But I believe we have to iterate towards these optimizations while balancing growth, whether that happens via the internal team or external community contributors. @RichCL already said it best:

Thank you again for your thoughtful analysis here @poktblade. Piggyback’ing @RichCL’s one last time to echo the appreciation for your diligence and acknowledging these concerns are valid, but I hope the additional context provided makes our strategy for Triforce clearer.

Should tech support issues arise in the context of chain servicing, will it be the job of the Triforce shard members to provide that assistance?


Good question. It honestly depends on the support scenario. Generally the expectations are to keep nodes synced, provide altruist/backups, triage with applications on chain specific API/RPC configurations, and escalate issues to the Pocket Network internal team where necessary.

Here are the current support expectations as outlined in the Shard Maintenance Playbook:

There are expectations for shards, particularly DevOps and Business Development shard members, to proactively provide support and be available to the Pocket Network community.

Support scenarios include:

  • Actively monitoring the health of the shards node to ensure up-time, node syncing and health
  • Triaging API/RPC configurations directly with supported applications
  • Escalating “worst case scenario” and protocol related issues to the Pocket Network DevRel team
    • Chain halts
    • All traffic going to backups (altruists)
    • Nodes completely out of sync
  • Being accessible via the Pocket Network Discord or other public channels to answer chain specific node runner or app developer questions
  • Connecting app developers with relevant chain community contacts

While the expectation is not to be the frontline of Pocket Network support, shard members should be capable of owning the above chain services and routing additional requests accordingly.

You can see the full playbook in the Triforce docs. Hope that helps!

I think this is really interesting and should be its own proposal for consideration.

This proposal has been approved with 20 yes votes and 1 no vote.


Experience with Solidity creating NFT’s, Tokens and DAO’s…

Open Zeppelin and DAOstack…