Learn Pocket


Decentralizing Web3 Access

Web3 is built on incentives.

Blockchains enable unstoppable validation of transactions by incentivizing validator nodes, with mining/staking rewards, to confirm transactions. However, while this ensures an unstoppable history of transactions, it doesn’t ensure unstoppable access to read the history or to write new transactions to the history.

Many blockchain communities have debated incentivizing the RPC nodes that provide this access to the blockchain. Facing quite a complex challenge though, they have rejected on-chain solutions, expecting that altruists would run RPC nodes for the good of the network.

However, in the name of convenience, as RPC nodes have grown more expensive to maintain and developers more specialized, Web3 RPC access has consolidated around centralized gatekeepers. When you use MetaMask to sign transactions in your favorite game or NFT marketplace, assuming you haven’t already switched your custom RPC to Pocket Network, your data is flowing through a centralized cluster of RPC nodes. This means you are vulnerable to outages.

Pocket Network solves this critical flaw in the Web3 stack by incentivizing a network of RPC nodes to relay your data to any blockchain. DApps send their RPC requests to the nodes, who relay the requests and use Zero-Knowledge Range Proofs to validate the Relay Evidence that determines their POKT block reward. As well as making Web3 access unstoppable, this has the side effect of making Web3 infrastructure cheaper, by eliminating rent-seeking intermediaries, and more private, since each RPC node relays only a fraction of your data.

Learn more about Pocket Network’s current protocol.

Learn more about v1, the future of Pocket Network’s protocol.

How POKT Incentivizes RPC Nodes

Pocket Network’s unstoppable Web3 access is powered by the POKT utility token.

Applications stake POKT to lock in an RPC relay allowance, then transfer value to nodes through dilution of their stake proportional to the number of relays they request. Meanwhile, RPC nodes are participating in a perpetual fair-launch economy in which tokens are continuously rewarded to the nodes who do the most work.

This economic model has the following benefits:

  • Minimizes the number of transactions needed to coordinate the network, enabling cheaper RPC access. Per-relay micro-transaction payment models, on the other hand, would needlessly congest block space.
  • Provides extra incentive to apps to be early adopters of Pocket Network. When using Pocket Network, RPC infrastructure becomes an asset, literally. Apps make an upfront investment by staking POKT, which means they don’t need to worry about monthly bills and their cost-per-relay approaches zero the more relays they use. This makes Pocket Network’s RPC service very attractive compared to the competition in the long run.

Once the POKT ecosystem is mature, when apps can frictionlessly top-up their stakes, and we no longer need bootstrapping incentives, the protocol has a dormant burning mechanism that the DAO can activate to burn app stakes proportional to the number of relays they request. This will have the effect of transforming Pocket Network’s business model into a standard credit system and making POKT deflationary.

Learn more about Pocket Network’s economics and also the future of Pocket with v1.

Decentralizing Infrastructure

We posit that application-specific blockchains like Pocket Network have the ability to design greater cost efficiencies at the base protocol layer of the Web3 stack while enhancing security and censorship resistance.

Pocket achieves this through an incentive design that rewards Service Nodes for collectively achieving economies of scale:

  1. Load balancing at the protocol level incentivizes decentralization and minimizes the need for buffers
  2. Staking and inflation enables more efficient resource allocation
  3. Low marginal costs reduce barriers to entry, allowing anyone to participate at any scale

Load balancing at the protocol level

Due to the protocol using pseudo-random mechanisms to load balance work evenly across all nodes in the network, the optimal deployment strategy for node providers is to horizontally scale the number of Service Nodes they run (rather than to scale vertically by increasing the POKT stake of the Service Nodes they already have) to increase the probability that they’ll receive work. By decreasing the average work per Service Node, participants of all scales are encouraged to provision their computing power to Pocket Network. This aspect of Pocket’s system design means Pocket Network’s node counts will increase as it scales.

To minimize the marginal cost of each Service Node, it will ultimately become more profitable to run nodes out of homes and local data centers, which will, over time, create a lower-cost, more efficient decentralized network.

Pocket’s distributed nature makes it redundant-by-design, removing the need for node operators to provision extra infrastructure to handle surges in user traffic. Web2 cloud-powered infrastructure requires large buffers of redundant server capacity, which can increase the costs of coordination borne by Web3 users by up to 50%. Conversely, instead of one entity providing all the work, Pocket Network naturally splits demand up amongst Service Nodes through its Session data structure, tumbling new, pseudo-random nodes every Session to give all Service Nodes the opportunity to provide work. As a result, the buffer that each Service Node must provide is significantly lower. Additionally, because Applications must stake POKT to access the service, Service Nodes can account for all potential requests paid for in aggregate, using Application Stake as a gauge of network capacity.

Staking and inflation

For a decentralized infrastructure service like Pocket Network, on-chain payments via Bitcoin, ETH, or DAI would be inefficient due to the frequency of Relay requests. While state channel implementations do improve the cost of coordination for micropayments, Pocket matches Applications with 5 pseudo-random Service Nodes every 25 blocks for security purposes; creating and breaking on-chain state channels to communicate with each of these nodes would make the cost of coordination impractically high.

Pocket uses Proof-of-Stake (PoS) to secure the state machine and falls under the umbrella of generalized mining or useful proofs of work, where inflation is directly tied to work validated by the network. Applications stake just once to access the protocol (assuming they don’t change their throughput), using the native cryptocurrency POKT which is tied for single-use to the Pocket blockchain. Service Nodes batch all requests received in a Session to one Pocket blockchain transaction, a “Proof-of-Relay” that Applications can validate client-side and other nodes can validate in block production, removing the need for Applications to pay constant transaction fees for this work. Once those Proofs-of-Relays are validated by the network, a new block is confirmed, then POKT is minted and issued to the relevant Service Nodes as a reward for their work.

Pocket’s staking and inflation mechanisms enable a more efficient resource allocation structure by limiting the number of transactions (and thus block validation costs) to one-time staking transactions. All nodes are able to focus primarily on servicing and validating Relay requests by Applications, with minimal energy spent on block validation. By being eventually consistent and tying rewards directly to inflation, Service Nodes are in effect, receiving micropayments for work validated by two parties without the need for constant on-chain fee payments.

Low marginal costs and participation

The marginal cost of running an individual Service Node is only as high as your electricity and bandwidth costs, ensuring a low barrier to entry for new Service Node operators. Because work is load balanced evenly across the protocol, the stake, size, or capabilities of the Service Node does not increase the probability of receiving work, which enables hobbyists and small providers to participate and contribute alongside major infrastructure providers. As smaller Service Node operators scale up, they can then choose to bear the costs of hardware, equipment, and salaries needed to add more Service Nodes to their operation.

While the bulk of work will most likely be serviced by professional infrastructure providers, Pocket also enables a long tail of individuals to participate and increase the resilience of the protocol, with potential for upward mobility for those who choose to purchase more Service Nodes.

Product Comparisons


Examples: The Graph, Covalent

Indexers are complementary services.

Indexers organize data, but they still need nodes to communicate with the blockchain. They could either run their own nodes, use a centralized API like Infura or Alchemy, or use Pocket Network’s decentralized API for an extra layer of redundancy. Outsourcing node management to a decentralized API is likely to be more cost-efficient for indexers because it will enable them to focus on optimizing their indexing setups.

For apps, while indexers are useful for more efficiently querying the chain (read), they don’t provide the RPC access needed to submit transactions to the chain (write). Not all apps will need an indexer, but they will need an API (either Pocket’s decentralized API or a centralized alternative).

Centralized APIs

Examples: Infura, Alchemy

Pocket Network is a protocol; centralized API providers are businesses.

Pocket Network connects you to a network of thousands of nodes, run by a variety of operators on a variety of hardware. Centralized API providers connect you to the hardware that they own and operate.

The key differentiator between these arrangements is that Pocket has an inherent diversity at scale that makes its service more resilient and less likely to face downtime.

For example, in November 2020, there was a consensus bug that affected specific versions of Geth, a client that Infura relied on heavily. As a result, Infura “experienced its most severe service interruption in our four years of operation”. Pocket Network, being more inherently diverse in its architecture, experienced no such outage.


The Pocket Network is comprised of 3 components: Applications, Nodes and the Network Layer.

An Application submits Relays, or API requests meant to be routed to any public database node. Nodes service these Relays, by submitting them to the public databases they are meant for, and sending the response (if any) back to the Application. The Network Layer is comprised of all the rules, protocols and finality storage that serve as the backbone of the interactions between Applications and Nodes, including (but not limited to), configuration, record tracking, governance and economic policy.

The mechanism the Network uses to regulate the interactions between Applications and Nodes are Sessions. Sessions are a data structure that are generated following the established Session Generation Algorithm, which uses data from the finality storage layer of the network to pseudo-randomly group one Application with a set of Nodes which will provide service to it for a limited timeframe.

To dive deeper, start by learning more about Sessions.



The Pocket Network’s Servicing layer is comprised of 2 main actors: Applications and Servicers. An Application submits a Relay Request, or an API requests to be routed to any Relay Chain. A Servicer ‘services’ the Application, by routing the Relay Request to the Relay Chain and forwarding the response to the Application. This interaction between an Application and a Servicer is the fundamental utility of Pocket Network.

Basic Lifecycle

  1. To register for decentralized infrastructure, an Application must stake the native cryptocurrency POKT in the network.
  2. The amount of the sanctioned throughput (per request) is determined by the amount the Application stakes in the network.
  3. To register to provide decentralized infrastructure, a Servicer must stake the native cryptocurrency POKT in the network.
  4. After the subsequent staking, an Application is paired with Servicer(s), during which time the servicing interaction takes place.
  5. For providing the decentralized infrastructure, Servicer receives an amount of the native cryptocurrency POKT proportional to the amount of throughput (in requests) served.
  6. Once an Application or Servicer unstakes, they are unregistered from Pocket Network and the stake is returned to their account.



The Servicer(s) that are paired to service an Application in a Session are equally distributed among all of the Servicers in the network.

Meaning that every Servicer theoretically serves the same amount as their peers and every Application theoretically will be evenly serviced by each Servicer over time.


The generation of a Session is key to the equal distribution property.

Equally distributed sessions are generated with pseudorandom seed data:

  • BlockHash: Hash of the last Session Block
  • AppPubKey: The Application’s public key
  • RelayChain: The identifier of the Relay Chain

The result of using this seed data is unique sessions for every Relay Chain of Application at any given Session period.

The Servicers over time that will serve each Application at any given time are extrapolated using this data, meaning any actor with the following blockchain data is able to generate the proper serving Servicers.

A single Dispatch API call to any full node on Pocket Network will provide an Application client with the ServiceURI of their Session period Servicers.


Tumbling is the act of regenerating a Session with new seed data.

Sessions are tumbled periodically every predetermined (by governance) quantity of blocks.

The tumbling mechanism allows for much greater Application security, as the same Validator(s) will only service the Application for a certain amount of time.


The max Application throughput (in number of requests) is proportional to the amount staked.

The maximum a Servicer in a Session can service for a certain Application is determined using the following formula:

max_app_relays = base_throughput / (# of Servicers in Session * # of relay_chains staked for)



The request payload is the body of the RPC request

  • Data: The actual request body to be forwarded to the Relay Chain
    • e.g. {"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}
  • Method: The HTTP CRUD method
    • e.g. POST
  • Path: Path variable for REST support
    • e.g: "/v1/query/block"
  • Headers: HTTP Headers
    • e.g. Content-Type: application/json


The Relay Metadata is Protocol level descriptive information that is needed for servicing.

  • BlockHeight: The Pocket Network block height when the request was made

The metadata mechanism allows for a configurable client syncronization module, enabling the Servicer to reject out of sync clients.

Since the Metadata is grouped into the request hash, this mechanism is a protection against Client level synchronization attacks where the Client is able to challenge single Servicers by requesting chain data at a different time than the majority.

Proof of Relay (Evidence)

A Proof of Relay is the portion of a Relay Request that is used for verification of the atomic work completed.

For each Application of each Session, a Servicer collects Relay Evidence in the form of a Proof of Relay. The amount of Relay Evidence is completely proportional to the amount of Relays serviced, meaning for each Relay successfully completed, the Servicer stores one piece of Relay Evidence.

Structure of the Proof of Relay

  • RequestHash: The SHA3-256 hash of the request payload
    • Connects the specific payload with the proof
    • Needed for the Application Challenge Mechanism
  • Entropy: A unique nonce (random number) that ensures uniqueness
    • Unique Relays are a requirement of Pocket Network for Claim/Proof Submission
    • Collisions are rejected by the Servicers
  • SessionBlockHeight: The block height of the session when the Relay was serviced
    • Needed to verify the participants of Session
  • ServicerPubKey: The ED25519 Public Key of the servicer
    • Needed to identify the servicer
  • RelayChain: The identifier of the ‘relayed to’ blockchain
    • Ex: 0021 (Eth mainnet)
  • AAT: The Application Authentication Token for the client serviced
    • Includes both App Public Key and Client Public Key
    • Needed for protocol level verification (app node pairings, client permissions, etc.)
  • ClientSignature: The Elliptic Curve Digital Signature of the client
    • Preserves the integrity of the Relay data
    • Needed at Proof/Claim verification level


Response Payload

The response payload is the body of the RPC response:

  • Response: String representation of the HTTP response

Servicer Signature

The servicer signature completes the signature exchange needed to verify all parties in the servicing protocol.

  • Signature: preserves the integrity by signing the hash of the Proof of Relay and the response payload.

Claim/Proof Lifecycle

In order to participate in the network economic incentive mechanism, the Servicer must first Claim and then Prove the completed work. For each Application of each Session, after servicing is complete and Relay Evidence is collected, the Servicer must send two subsequent transactions:

  1. Claim Transaction
    • Merkle Root of Relay Evidence
    • Number of Relays serviced
    • Evidence Type (Relay or Challenge)
  2. Proof Transaction
    • Selected Relay
    • Corresponding Merkle Proof for selected Relay
    • Evidence Type (Relay or Challenge)

Upon successful completion of BOTH transactions, the Servicer is minted reward directly to their address.

Merkle Tree

Pocket Network requires a specific Merkle tree implementation that ensures no two leafs of the Merkle tree are identical (for Relay replay protection). Plasma-Core’s Merkle sum tree satisfies this property.

By using the hash of the Relay data (integrity is validated by verifying the Application Client Signature) in conjunction with the replay protection from the Plasma tree, Pocket Network can probabilistically guarantee work completed without the Servicer actually transmitting the entirety of its Relay Evidence to the rest of the network.

A fancier name for this is a Zero Knowledge Range Proof.

Zero Knowledge Range Proof

In order to complete a successful ZKRP in Pocket Network, the following steps must be executed by each Servicer for each Session:

  1. Generate the Merkle Tree using the SHA3-256 hash of the Relay Evidence as the leafs
  2. Submit a Claim Transaction to preserve the integrity of the local Merkle tree and corresponding Relay Evidence, as well as inform the protocol of the range or number of leafs possible to select from
  3. After a protocol wide waiting period (determined by governance), the Servicer generates the selected leaf (using the latest block hash as pseudorandom entropy to prevent knowledge of the selection during claim generation) and subsequently creates a Merkle Proof (branch) for the pseudorandomly selected leaf.
  4. The Servicer submits a Proof Transaction containing the selected leaf (Relay Evidence) and the corresponding Merkle Proof (branch)
  5. The protocol verifies the Merkle proof against the previously submitted Merkle root (in the Claim Transaction), verifies the session (proper app/node pair, not overserviced etc.), and then verifies the client signature against the Proof of Relay (integrity check)
  6. All of the Validators confirm the validity of the Proof Transaction, completing the Zero Knowledge Range Proof
  7. Tokens are minted to the address of the Servicer proportional to the amount of Relays served.


By enforcing POKT to be staked from both the Applications and the Validators, the protocol is able to economically penalize either actor participating in servicing.

Session Security

The probability due to randomized selection without replacement is:

$$ P (A∩B) = P (A) P (B|A) $$

Thus the probability of selecting any combination of Validators at any given Session in Pocket Network is:

$$ 1 / (allvals (allvals-1) (allvals - 2) ... * (allvals - valspersession)) $$

Meaning, the more Validators in the network, the higher level of randomization and by extension security.

The deterministic yet unpredictable properties of the block hash seed data in Session Generation, ensure that no malicious actors will be able to determine Application and Validator pairings. This is a common security mechanism used in Pocket Network.

Application Security

The Application Authentication Token is the key mechanism for Applications to balance the security of their stake and UX of clients during servicing. Through the AAT, the Application is able to sanction clients to access their throughput via Digital Signature. Future implementations of the AAT include enforcing a lifecycle through expiration and other client access configurations such as Relay Chain specification.

Application Distribution Configuration is the recommended practice of distributing an Application’s throughput over multiple Application stakes (or identities) to ensure the highest level of data accuracy, uptime, and data privacy.

Client Side Validation is the recommended practice of redundantly sending the same request to multiple Validators. CSV allows the client to come to a majority consensus on the Relay Responses. This configuration ensures the highest level of data accuracy and enables the Application to use the Application Challenge Mechanism of the protocol, where corresponding minority Validator(s) providing invalid data are economically penalized.

Validator Security

A Validator will not receive mint for any service they provided while breaking the servicing protocol rules.

These rules are enforced by the Validators by verifying all the work reported to the network.

Examples of breaking the Servicing Rules include:

  • Overservicing an Application
  • Incorrect App/Validator Pairing
  • Incorrect Relay Chain
  • Non-Unique Proof of Relays
  • Invalid Merkle Root / Proof pairings
  • Invalid Application Authentication Token
  • A minority Validator in Client-Side Validation
  • Invalid Servicer in Proof
  • Below minimum Relay count



Pocket Network requires both developers and nodes to stake its native utility token, POKT, to participate in the network. Nodes earn rewards for fulfilling API requests for developers on a per request basis. POKT is permanently inflationary, but total supply will be capped through a burning mechanism put in place by the DAO, who controls the monetary policy. The final total supply of POKT will be dictated by the DAO.


Pocket Network uses a native cryptocurrency (POKT) to create a permissionless, two-sided market between node providers who run full nodes and developers that want to query data from a blockchain for their application/service. POKT is purchased and staked by both developers and node providers to participate in the network. Due to the unique incentives on each side of the market, staking differs between the parties.

Developers, requiring reliable infrastructure and relay amounts for their applications, stake POKT a single time for a guaranteed amount of relays per session for the life of the stake. The amount of POKT required to be staked is directly proportional to the number of relays required. The number of relays allowed per session can be adjusted for price fluctuations of the POKT token through governance mechanisms.


The current price per relay is called BaseRelaysPerPOKT, and you can find the current value on the Protocol Parameters page.

While paying upfront for infrastructure appears to be burdensome at first glance, it has strong advantages and stickiness that help grow network adoption. The use of a token eliminates recurring payments to legacy infrastructure providers, vastly reducing the cost of infrastructure over the lifecycle of an application - bringing your cost-basis closer to zero the longer the service is used. Further, the upfront purchase of POKT can be viewed as a recoverable expense because the stake can be sold to another user if the service is no longer required helping to recover any costs associated with the network’s use. Instead of recurring payments, developers’ stakes are diluted over time through the inflation of the supply of POKT.

Node Providers also stake POKT but do so on a per-node basis. In exchange for servicing relays for applications, nodes are compensated in POKT. Unlike most traditional block rewards, Pocket Network’s is dynamic; POKT rewards are directly proportional to the number of relays and transaction fees in a given block. A node receives a certain amount of POKT per relay fulfilled and proved, minus certain percentages for both the block producer and the DAO.


The current block producer percentage is called ProposerPercentage, and you can find the current value on the Protocol Parameters page.

Furthermore, the DAO allocation of block rewards is called DAOAllocation, and that also can be found on the Protocol Parameters page.

All nodes in the network have an opportunity to produce a block, but their chances are proportional to their stake.

Because of the way that nodes are incentivized, the Pocket Network economic model is inflationary during the Growth Phase, where the monetary policy is intentionally designed to encourage adoption. At network maturity, the Maturity Phase, a burn rate will initiate for application stakes that will offset the creation of newly minted POKT, stabilizing the total supply of POKT. This economic model encourages early network participation and reduces coordination costs.

At launch, the optimal economic strategy for node operators is to replicate as many nodes as possible with the amount of POKT held. By spreading their stake across multiple nodes, node operators maximize their chances of being chosen in as many sessions as possible, providing them with the most opportunity to serve relays within the network. These incentives promote further decentralization, redundancy, and increase the number of nodes available for each blockchain network supported by Pocket Network.

Maintaining a balance between both sides of the market will be critical to the long-term success of the network. To maintain and secure the future of the protocol, Pocket Network will be run by the Pocket DAO. To accomplish its mission, the DAO receives a certain percentage of block rewards to reinvest in the network. In addition to protocol upgrades, the DAO will dictate the economic policy, making every effort to create sustainable economics that caters to both sides of the market through built-in governance mechanisms. These governance mechanisms allow the DAO to maintain an equilibrium between the two sides of the market and ensure accessibility to new participants.

Token Economics

The Purpose of POKT

POKT is not a transactional cryptocurrency. The Pocket Network blockchain is not meant to have sub-5-second block times, provide 10,000 transactions per second, facilitate direct payments (generally speaking), or act as a smart contract platform. The majority of the transactions occurring will be staking by Applications and Service Nodes, Proof-of-Relay batches by Service Nodes, and block reward payments to Service Nodes for facilitating Relay requests, which all POKT holders will pay for via inflation.

This is in contrast to most layer 1 chains, which will eventually need to rely predominantly on transaction fees. At network maturity, Pocket will become a simple fee market with the demand side (Applications) burning POKT and the supply side (Service Nodes) receiving newly minted POKT via the block reward inflation mechanism. This allows for the transfer of value without using direct fees and incurring further costs of coordination.

By building a set of crypto-economic mechanisms to ensure the validation of Proofs-of-Relays, Pocket’s architecture can provide blockchain infrastructure at an order-of-magnitude lower cost than other options by virtue of being a permissionless, non-rent-seeking, and open marketplace for anyone to participate. Pocket Network uses these validated Proofs-of-Relays to reward Service Nodes through inflation.

Both Applications and Service Nodes must stake POKT to access or provide work to Pocket Network. For Applications utilizing the Pocket network, POKT represents an ongoing right to an allocation of the network’s throughput, whereas, for Service Nodes, POKT represents a right to provide ongoing work on the network and the future inflation rewards for performing that work.

Useful Proofs of Work

Pocket uses Proof-of-Stake (PoS) to secure the state machine and falls under the umbrella of generalized mining or “useful proofs of work.” Submitting proofs of work mints POKT in proportion to the amount of work completed increasing the overall supply of POKT. How this affects the overall supply is determined by the monetary policy.

Our current monetary policy is broken down into two phases: the Growth Phase and the Maturity Phase. During the Growth Phase, applications stake just once to access the protocol (assuming they don’t change their throughput) attracting new applications to use the service due to the low cost of service - only paying through their initial stake and through inflation. At network maturity (the Maturity Phase), Pocket will become a simple fee market with the demand side (Applications) stakes are burned in proportion to the amount of POKT minted by the supply side (Nodes) - eliminating the growth in total supply of POKT. This allows for the transfer of value without using direct fees and incurring further costs of coordination.

For more information, read our page on Pocket monetary policy.


Leader-elected nodes are rewarded for facilitating P2P transfers of POKT on the Pocket blockchain via a transaction fee. This is required for the security of the network in order to prevent spam or “dust” attacks. A transaction fee is paid by the individual or entity making a transaction, 99% of which is burned, and the remaining 1% is awarded to the leader-elected node for including transactions in the relevant block. The 1% fee provides an incentive for block producers to include transactions in the next block.

Token Staking

There are two distinct types of stake functions within Pocket: StakeApp() and StakeNode(). Both stake functions use the POKT cryptocurrency.

Application Staking

Applications pay for the service in advance by staking POKT. When they invoke the StakeApp() function, the minimum staking period is 21 days. By incurring the minimum unstaking period, Applications forego the potential of using their resources, POKT in this case, for other alternatives as an opportunity cost. Additionally, Applications pay through dilution, where each time a Relay is serviced and validated by the network, a specific sum of POKT is awarded to the relevant Service Nodes in the next block reward.

The protocol limits the number of Relays an Application may access based on the number of POKT staked in relation to the Protocol Throttling Formula (as defined below). Once an Application stakes POKT, the Maximum Relays (MaxRelays) it can use is locked in perpetuity unless the Application re-stakes that POKT or their stake is burned.

Node Staking

Like with applications, when nodes invoke the StakeNode() function, the minimum staking period is 21 days. The minimum stake at launch required to become a Service Node is 15,000 POKT. This node stake keeps nodes honest and incentivized to provide high quality service. Additionally, a node sufficient stake allows nodes to participate in PoS consensus as a Validator Node. Per the changes in R.C.0.6.0, not all nodes are validators, but all validators are service nodes. To become a Validator Node, you must be in the top 1,000 node stakes (subject to change on DAO parameter vote) on the network. Validator Nodes can claim the block reward for submitting the block which is equal to the value of the ProposerPercentage parameter.

While the Minimum Node Stake is 15,000 POKT, we highly recommend staking an amount greater than 15,000 the minimum in case of slashing that may be caused by misconfiguration. Node runners have reported a stake of 15,100 POKT is a best practice.

POKT Denominations


The current denomination used by the protocol is defined by the StakeDenom parameter. When using the Pocket CLI or PocketJS library to send transactions to the network, you will need to use this denomination.

10^0uPOKTMicro or ‘you’POKT
Upper Bound = 9,223,372,036,854,775,807,000,000 STAKED uPOKT

App Economics

Pocket Network is a developer-driven protocol, with demand from applications driving the rewards the service nodes earn. Applications use Pocket Network to retrieve data and write state to and for their blockchain applications. Each relay that is created by an application results in the creation of newly-minted POKT as a reward for the service nodes facilitating such relays. Applications stake just once to access the protocol (assuming they don’t change their throughput), using the native cryptocurrency POKT.

Once an application stakes POKT, its maximum relay count is locked in perpetuity unless the application re-stakes that POKT or their stake is burned.


Direct application staking isn’t currently available. We aim to implement this feature in the beginning of 2023.

Currently, the way to connect Pocket to your applications is through the Pocket Portal. You can mint an Endpoint in the Portal for any supported blockchains which you can then use in your dApps. You can get up to 250,000 relays per day for free, with other paid options available. Read more about the Portal.

Calculating Throughput

When applications stake POKT, their rate for the number of relays they may access (MaxRelays) is locked in for the entire length of the stake. Due to the oracle problem, the protocol cannot infer external factors that might influence the market price of POKT, or therefore account for these factors. This introduces a risk to the demand side of the protocol, where fluctuations in the market price of POKT may affect the price applications must pay for relays.

We aim to allow the market to find a USD Relay Target for POKT, to ensure the real price borne by applications is within a relatively stable and acceptable range. This USD per Relay target is not an on-chain variable, but a publicly agreed price that the DAO will target with its monetary policy.

Relays per staked POKT for a given session is calculated by:

$$ \text{Relays per Staked POKT} = \frac{\text{POKT price in USD (30 day avg)}}{\text{USD Relay Target}\times\text{Sessions per day}\times\text{Avg days per month}\times\text{ReturnOnInvestmentTarget}} $$

For example, given a POKT price of $0.12, a USD Relay Target of $0.00000361 per relay, and a ReturnOnInvestmentTarget of 24 months:

$$ \text{Relays per Staked POKT} = \frac{\text{\$0.12}}{\text{\$0.00000361}\times\text{24}\times\text{30.42}\times\text{24 months}} \approx \text{1.90} $$

The on-chain parameter BaseRelaysPerPOKT is defined as the above Relays per Staked POKT multiplied by 100, so as to allow for more granularity on-chain. This parameter will be updated at the discretion of the DAO.

Another related value of importance is BaseThroughput. This is not an on-chain value, but instead a calculation of the total application stake, the total amount of relays your application receives after staking.

The BaseThroughput for a given session is calculated as the product of the Relays per Staked POKT (defined above) and the total amount of POKT staked:

$$ \text{BaseThroughput} = \text{Relays per Staked POKT}\times\text{Total Staked POKT} $$

This value is constant for the life of the application stake, so regardless of whether the price of POKT or any other input value changes, the BaseThroughput will remain the same. You can think of this as the value that’s locked in for the duration of the stake.

From all this, you can compute the amount of staked POKT required based on the daily average relays you expect your application to use.

$$ \text{Required Staked POKT} = \frac{\text{Daily Average Relays Required}}{\text{Relays per Staked POKT} \times \text{Sessions per day}} $$

For example, consider an application with a need for 1,200,000 relays per day. That corresponds to a per session relay count—or BaseThroughput—of 50,000 relays.

Given a value of Relays per Staked POKT of 1.9 (so a BaseRelaysPerPOKT value of 190), the amount of POKT that would be required to be staked is:

$$ \text{Required Staked POKT} = \frac{\text{1,200,000 relays per day}}{\text{1.9} \times \text{24}} \approx \text{26,316 POKT} $$

And recall that even if the price of POKT or any other values change, your initial stake of this amount would guarantee that daily average relay count of 1,200,000 for the duration of the application stake.

Node Economics


Pocket uses Proof-of-Stake (PoS) to secure the state machine and falls under the umbrella of generalized mining or useful proofs of work, where inflation is directly tied to work validated by the network.

Service Nodes batch all requests received in a session to one Pocket blockchain transaction, a “Proof-of-Relay” that applications can validate client-side and other nodes can validate in block production, removing the need for applications to pay constant transaction fees for this work. Once those Proofs-of-Relays are validated by the network, a new block is confirmed, then POKT is minted and issued to the relevant Service Nodes as a reward for their work.

Service Nodes are pseudo-randomly assigned to a Session. New Sessions get created every 4 blocks with a new, pseudo-random set of Service Nodes.

Nodes have a better chance of being picked to service relays based on their service quality. Furthermore, nodes that stake more POKT, while not improving their chances of receiving relays, will get a greater reward when serving a relay, compared to a node with less POKT staked. (See the section on Stake-Weighted Servicer Rewards for details.)

Node Staking

Like with applications, when nodes invoke the StakeNode() function, the minimum staking period is 21 days. The minimum stake at launch required to become a Service Node is 15,000 POKT. This node stake keeps nodes honest and incentivized to provide high quality service. Additionally, a node with sufficient stake allows nodes to participate in PoS consensus as a Validator Node. Per the changes in RC-0.7.0, not all nodes are Validator Nodes, but all Validators are Service Nodes. To become a Validator Node, you must be in the top 1,000 node stakes on the network (as determined by the MaxValidators parameter). Validator Nodes can claim a block reward percentage for submitting the block equal to the value of the ProposerPercentage parameter.


While the Minimum Node Stake is 15,000 POKT, we highly recommend staking an amount greater than the minimum in case of slashing that may be caused by misconfiguration. Node runners have reported a stake of 15,100 POKT is a best practice.

Distribution of Service Nodes

While Pocket Network will depend on professional infrastructure providers to provide the bulk of the infrastructure for applications, due to the low marginal cost of running a full Service Node, we expect there to be a long tail of individuals running Service Nodes. There are two primary objectives that the network will focus on to avoid any stagnation in the number of Service Nodes in the network:

  • Continuing to lower the barrier to entry for non-technical users to run full nodes by providing clear documentation as well as technical support in the bootstrapping days of the network
  • Ensuring that the minimum stake to become a Service Node within Pocket is kept low enough to maximize the number of nodes within the network

Additional efforts to prevent stagnation include supporting distribution channels such as local mining pools through data centers, run-your-own node distribution partners and the Pocket DAO’s R&D efforts.

Incentivizing the long tail of individuals running Service Nodes and keeping barriers to entry low is important to keep large node providers honest, and to minimize the odds of having an entire set of Service Nodes in a Session owned by one entity, which could lead to collusion attempts.

Cost to Nodes

Upfront costs

There are two initial costs to becoming a Service Node:

  • Minimum Node Stake
  • Hardware (if chosen)


Pocket Network is neutral to the hardware utilized by Service Nodes, meaning that hardware can be a physical server that is run in a home or a local data center, or computing power can be purchased through popular cloud providers. The specs required for a Service Node’s hardware is dependent on the blockchain(s) that a Service Node chooses to support. For example, if a Service Node were to choose to support Ethereum, the server would need to have at least 1TB of storage (as of writing) to support an archival node for Ethereum.


The minimum stake at launch required to become a Service Node is 15,000 POKT. This minimum stake also allows Service Nodes to participate in PoS consensus. If a Service Node stake falls below the minimum amount through serving incorrect data or incorrect block validation, 20% of the minimum stake for that Service Node will be slashed and jailed. If a Service Node submits a fraudulent Relay batch, 100% of their stake will be slashed. The initial amount of POKT needed to stake as a Service Node is not dynamic, but can be raised or lowered by the Pocket DAO to ensure a stable barrier to entry.

Once the initial costs of a Service Node are covered, the only additional cost is electricity and bandwidth for providing the computing power to complete Relays. Marginal costs for Service Nodes are extremely low and increase linearly as work increases.

Recurring costs

  • Cloud providers
  • Electricity
  • Bandwidth
  • Data center

Outside of the fixed costs associated with running a node, Service Node operators will also incur costs like electricity, data center fees, and bandwidth costs for physical hardware. Alternatively, if they opt for a cloud-hosted service, they’ll be paying an all-in fee for hosting. Again, these marginal fees are low, but will play a factor in node profitability and total node counts.

Economic Security

The initial amount of POKT needed to stake as a Service Node is not dynamic, but can be raised or lowered by the Pocket DAO to ensure a stable barrier to entry.

Jailing and Slashing

  • Jailing a node removes them from both protocol service and consensus.
  • Slashing a node burns a percentage of the staked tokens.

A node is jailed and subsequently slashed for not signing (or incorrectly signing) block proposals. More often than not, this is the reason why nodes are jailed.

If a Validator falls below the minimum stake (due to slashing), the protocol will forcibly unstake the validator and start the unstaking waiting period. This feature of the protocol highlights the importance of staking ‘well above’ the minimum stake.

Jailing Penalties

A Pocket Validator Node can be jailed for 1 of 2 reasons:

  1. Fails to produce min_signed_per_window amount of blocks over a signed_blocks_window. When jailed because of this reason, a Pocket Validator Node is Slashed a slash_fraction_downtime% of their Stake.
  2. For Double Signing a Block. When jailed because of this reason, a Pocket Validator Node is slashed a slash_fraction_double_sign% of their Stake.

When a Pocket Validator Node becomes Jailed, it remains in the Staked list of Pocket Validator Nodes, however it becomes ineligible to become for Block Production or participating in Sessions. In order to become Unjailed again, and after waiting downtime_jail_duration nano-seconds, a Node Unjail transaction must be sent to the Pocket Network, and upon approval, the Pocket Validator Node will become Unjailed again.


If a Pocket Validator Node is left jailed for max_jailed_blocks blocks, it will be Force Unstaked.

Double Sign Penalties

0.0001% percentage of the validator’s stake that will be slashed upon reporting of double vote Evidence type from Tendermint, where a double vote on a block is/can be a submission for two differing states, transactions, apphashes, etc. and result in a forked network.

Relay Challenges

In order to participate in the network economic incentive mechanism, the Validator must first Claim and then Prove the completed work.

Burning for Bad Fraud Proofs (Replay Attack)

If a Service Node submits a fraudulent Relay batch by attempting a replay attack, the validator’s stake will be slashed by the factor specified in the ReplayAttackBurnMultiplier parameter.

Economic Incentives

For providing infrastructure access to applications, Validators are rewarded proportional to the work they provide. Pocket Core attempts to send a Claim and subsequent Proof transaction automatically after the proof_waiting_period elapses. If both transactions are successful, Tokens are minted to the address of the Validator.


Read more about Pocket monetary policy.

Optimal Deployment Strategy

The considerations on how to stake your nodes have changed from when Pocket Mainnet was launched.

Initially, there was no incentive to stake more than the minimum amount of POKT. A node with 60,000 POKT staked would earn the same amount of rewards as a node with 15,000 POKT staked (assuming latency and all other aspects of service quality were the same).

Therefore, if a node runner wished to earn more rewards, and had fully optimized their node, they would spin up more nodes. Infrastructure costs scaled linearly with POKT rewards earned.

However, too many nodes can cause network slowdowns and inefficiencies. As of 2022, there were over 40,000 nodes running on the network, more than enough to service the number of relays being requested.

Thus, the community decided that there was a need to reduce the number of nodes on the network, but without negatively affecting existing node runners. This led to PIP-22: Stake-Weighted Servicer Rewards.

Stake-Weighted Servicer Rewards

Stake-Weighted Servicer Rewards incentivizes node runners to stake more POKT on their nodes by giving out a proportionally higher reward for the same service.

For example, this could mean that a node runner who staked twice as much POKT might receive twice the rewards for the same amount of relays serviced. (The details of the multiplier are on-chain parameters controlled by the DAO, and are subject to change.)


Staking more POKT does not affect session selection in any way. A node with a higher stake will be selected in the same way as any other node, but when rewards are earned, they may be at a higher multiplier.

These rewards multipliers are determined by organizing nodes of various stake amounts into one of a few “bins” (or “tranches”). Roughly, the higher the stake, the higher the bin number, and the greater the rewards. All nodes that are in the same bin will have the same reward multiplier, regardless of the specific amount of POKT staked.

There are four on-chain parameters that determine how the reward multipliers are calculated:

  1. ServicerStakeFloorMultiplier
  2. ServicerStakeWeightCeiling
  3. ServicerStakeFloorMultiplierExponent
  4. ServicerStakeWeightMultiplier

While the names may seem cumbersome, they do come together in a fairly straightforward way, as described below.

ServicerStakeFloorMultiplier (“The Width”)

This parameter denotes the size (or width) of the bins. The value here denotes the amount of POKT can vary among nodes to still be considered in the same bin.

When this feature was first implemented, the value was equal to 15,000 POKT, meaning that a node could stake anywhere from (for example) 15,000 POKT to 29,999 POKT and still receive the same reward multiplier.


The actual parameter is denoted in uPOKT, but is listed here in POKT for easier comprehension.

ServicerStakeWeightCeiling (“The Ceiling”)

This parameter denotes the minimum value of the top bin. Any amount staked higher than this value will not incur any greater reward.


If the amount of POKT staked is higher than the Validator Threshold, the node will earn additional rewards due to being a Validator Node. However, that is unrelated to Stake-Weighted Servicer Rewards.

When this feature was first implemented, the value was equal to 60,000 POKT, meaning that a node that staked 60,000 or more POKT would always receive the largest multiplier of rewards.


The actual parameter is denoted in uPOKT, but is listed here in POKT for easier comprehension.

The number of bins isn’t a parameter, but can be inferred from the values of ServicerStakeFloorMultiplier, ServicerStakeWeightCeiling, and StakeMinimum as per the following:

$$ \text{Number of bins} = \frac{(\text{ServicerStakeWeightCeiling} - \text{StakeMinimum})}{\text{ServicerStakeFloorMultiplier}} + 1 $$

Given the initial conditions supplied above, there are 4 bins.

$$ \text{Number of bins} = \frac{(\text{60000} - \text{15000})}{\text{15000}} + 1 = 4 $$

The amounts of staked POKT for each bin can be determined from this as well.

Bin NumberMinimumMaximum
460,000[No maximum]

ServicerStakeFloorMultiplierExponent (“The Exponent”)

The next two parameters determine not the bins, but the multipliers that are applied to those bins to get the final reward multiplier.

This parameter determines how the rewards scale per each bin.

Assuming all else equal, with an exponent of 1 (the initial value when this feature was implemented) the bins would scale linearly:

Bin NumberBin with ExponentReward multiplier

Given the other initial conditions listed above, a node that has 30,000 POKT staked (Bin 2) would earn twice as many rewards for the same number of relays as a node that only has 15,000 POKT staked (Bin 1).

An exponent value of greater than 1 will incentivize node consolidation, as node runners will earn more by staking their POKT on fewer nodes. Similarly, an exponent value of less than 1 will disincentivize consolidation, because of the reduction in rewards.

ServicerStakeWeightMultiplier (“The Multiplier”)

This final parameter exists to offset the inflation caused by Stake-Weighted Servicer Rewards.

With increased rewards for the same amount of POKT staked, the new system of consolidated nodes would encourage inflation. This is an unintended side-effect, so the ServicerStakeWeightMultiplier was added in to offset the inflation, so that the amount of POKT created would be the same regardless of whether Stake-Weighted Servicer Rewards had gone into effect or not.

For example, if the way nodes are positioned in bins leads to an emission rate of 1.8 times of what would have been before, then this parameter would be set to 1.8 which would offset the rewards generated by exactly this amount.

This is the parameter most likely to be changed frequently, since it affects inflation most directly.

Calculating the reward multiplier

We can now calculate the reward multiplier for a single relay on a node, given its amount of staked POKT:

$$ \text{Reward Amount} = \text{RelaysToTokensMultiplier}\times\text{Reward Multiplier} $$ $$ \text{Reward Multiplier} = \frac{\text{Bin Number} ^ \text{ServicerStakeFloorMultiplierExponent}}{\text{ServicerStakeWeightMultiplier}} $$


$$ \text{Number of bins} = \frac{(\text{ServicerStakeWeightCeiling} - \text{StakeMinimum})}{\text{ServicerStakeFloorMultiplier}} + 1 $$

and the minimums of each Bin N ( $\text{Bin } N_\text{min})$ are defined as:

$$ \text{Bin } N_\text{min} = \text{StakeMinimum} + [(N - 1) \times \text{ServicerStakeFloorMultiplier}] $$

so the node’s Bin Number is $N$ when the following is true:

$$ \text{Bin } N_\text{min} <= \text{Amount of POKT staked} < \text{Bin }(N+1)_\text{min} $$

Examples of reward multipliers

The following may be helpful in illustrating how the reward multiplier is calculated, and so will focus on the differences between the bins.

We will also assume for all these examples that the StakeMinimum is 15,000 POKT, as it has always been.

  • ServicerStakeFloorMultiplier = 15,000 POKT
  • ServicerStakeWeightCeiling = 60,000 POKT
  • ServicerStakeFloorMultiplierExponent = 1
  • ServicerStakeWeightMultiplier = 1
$$ \text{Reward multiplier} = \frac{\text{(Bin Position)}^1}{1} $$
BinStaked POKTReward Multiplier
115,000 - 29,999$1^1 / 1 = 1\text{x}$
230,000 - 44,999$2^1 / 1 = 2\text{x}$
345,000 - 59,999$3^1 / 1 = 3\text{x}$
460,000+$4^1 / 1 = 4\text{x}$

If we change the multiplier to 1.5:

  • ServicerStakeFloorMultiplier = 15,000 POKT
  • ServicerStakeWeightCeiling = 60,000 POKT
  • ServicerStakeFloorMultiplierExponent = 1
  • ServicerStakeWeightMultiplier = 1.5
$$ \text{Reward multiplier} = \frac{\text{(Bin Position)}^1}{1.5} $$
BinStaked POKTReward Multiplier
115,000 - 29,999$1^1 / 1.5 = 0.67\text{x}$
230,000 - 44,999$2^1 / 1.5 = 1.33\text{x}$
345,000 - 59,999$3^1 / 1.5 = 2\text{x}$
460,000+$4^1 / 1.5 = 2.67\text{x}$

If we set the multiplier to 1.5 and change the exponent to 0.5:

  • ServicerStakeFloorMultiplier = 15,000 POKT
  • ServicerStakeWeightCeiling = 60,000 POKT
  • ServicerStakeFloorMultiplierExponent = 0.5
  • ServicerStakeWeightMultiplier = 1.5
$$ \text{Reward multiplier} = \frac{\text{(Bin Position)}^{0.5}}{1.5} $$
BinStaked POKTReward Multiplier
115,000 - 29,999$1^{0.5} / 1.5 = 0.67\text{x}$
230,000 - 44,999$2^{0.5} / 1.5 = 0.94\text{x}$
345,000 - 59,999$3^{0.5} / 1.5 = 1.15\text{x}$
460,000+$4^{0.5} / 1.5 = 1.33\text{x}$

Monetary Policy

Pocket’s staking and inflation mechanisms enable a more efficient resource allocation structure by limiting the number of transactions (and thus block validation costs) to one-time staking transactions. All nodes are able to focus primarily on servicing and validating Relay requests by Applications, with minimal energy spent on block validation. By being eventually consistent and tying rewards directly to inflation, Service Nodes are in effect receiving micropayments for work validated by two parties without the need for constant on-chain fee payments.

Allocation of Minted POKT

For each Relay served and validated by the protocol, POKT is added to the next block reward according to the mint rate. The following is a breakdown of each participant’s share of the block reward given no parameter changes.

ParticipantParameter NameCurrent Allocation
Service NodesN/A85%
Block ProducerProposerPercentage5%

Current values of these parameters (and all others) can be found on the Protocol Parameters page.


The value for ProposerPercentage has recently changed. Please see PUP-19 for details.

As part of the Proof-of-Stake consensus, each Service Node has a weighted chance of being selected to be the block producer for any given block based on the total amount staked for that given node. The block producer receives a portion of the entire block reward, as does the Pocket DAO, which provides continuous and sustainable funding for supporting the continued adoption and utility of Pocket Network.

Monetary Phases

As the Pocket Network develops, we envision the POKT monetary policy evolving through three stages: Bootstrapping, Growth, and Maturity. The following sections will discuss each of these phases. Note that some of these ideas are forward-thinking and so are subject to change.

Bootstrapping Phase

During the bootstrapping phase of the network, it is important to build a strong foundation for the service, securing as many individual entities running nodes as possible. We do this by creating an environment where it is simple and inexpensive for initial Applications to access the network, and significantly profitable for Service Nodes to provide infrastructure.

Application usage and traction dictate the initial rewards that the Service Node pool will receive. By decreasing the barrier to entry for Applications (freemium access, low cost), the demand for Relays should be high during the Bootstrapping Phase, providing the initial pool of Service Nodes with ample opportunities to earn the high rate of POKT awarded for Relays serviced in the bootstrapping phase of the network.

As inflation and revenue increase per Service Node, the potential for competition increases, as rational, profit-seeking agents discover the protocol. This creates the flywheel to spur the network effects of Service Nodes purchasing and using POKT to participate until an equilibrium is found.

As the Protocol Throttling Formula adjusts to market demands, Applications being able to purchase more Relays results in more revenue for Service Nodes, further increasing the incentive for existing Service Nodes to re-stake their earned POKT. Increased participation in Pocket Network from Applications and Service Nodes ultimately benefits all parties by providing new revenue opportunities for Service Nodes and improving the service and resilience of the network for Applications. Due to Pocket Network being a permissionless Proof-of-Stake protocol and Service Nodes having an extremely low marginal cost of operation, the barriers to entry are significantly lower compared to Proof-of-Work mining based protocols. Pocket’s economic primitives incentivize a diverse set of entities and individuals such as data centers, existing infrastructure providers and hobbyists to participate as node operators within the network.

Growth Phase

The growth phase is the period from launch which will see the greatest increase in the overall ParticipationRate of the protocol. When Applications stake during the growth phase, they earn more MaxRelays as the network grows (assuming they un-stake and re-stake), and don’t pay for anything else until the network has matured and the Application Burn is activated.

One result of this is inflation. It is a priority of the DAO to manage inflation in a manner that encourages sustainable growth of the Pocket ecosystem, protects rewards against a potential decrease in relays, and sensibly updates rewards as Pocket Network grows.

If both sides of the marketplace (Applications and Service Nodes) grow, there will be continuous demand for Relays resulting in Service Nodes spinning up new Pocket nodes to increase the number of Relays they can service.

Early Applications will receive more infrastructure throughput as the network grows providing an incentive to early adopters of the network. When both the percentage of POKT staked and Service Node margins begin reaching their equilibrium, the protocol will have entered its maturity phase.

See the section below on inflation for more details.

Maturity Phase

While the Growth Phase is inflationary, designed to incentivize active participation and supply-side staking for the security of the network, the Maturity Phase is designed to ensure the long-term sustainability of Pocket. The Maturity Phase is defined as the point in which Pocket Network has crossed equilibrium and the growth in inflation begins outpacing growth in the total staked supply of POKT.

This shift to long-term sustainability revolves around burning POKT to ensure the POKT supply is stable doesn’t lose its value as a form of consideration to Service Nodes. In this phase, Pocket becomes similar to traditional Software as a Service pricing models, where Applications must “top up” their stakes periodically to avoid going below their needed Relay limit.

This should result in a decline in the ParticipationRate and Service Node margins due to an imbalance from more supply than demand for POKT.

In addition, to ensure the continued sustainability of POKT, to retain reasonable margins for Service Nodes, and to eliminate unnecessary overinflation of POKT, the Pocket DAO may activate an Application Burn Rate (ABR) at the Maturity Phase. This means that any POKT minting is balanced out by Application stake being burned at the same rate.

Once activated, the ABR results in a shift from Applications paying through dilution, to Application POKT being burned on a block by block basis to balance the minting of POKT as inflation awards to Service Nodes.

The effect of this is a logarithmic decay until the minimum App stake of 1 POKT is reached. Unless an Application increases the number of POKT they have staked, their holdings will fall under their desired amount causing applications to “top up” their stakes turning the network into a self-sustaining SaaS-like infrastructure protocol.

The rate of Application burn is determined by using indicators such as the decay in the growth of Application and Service Node stake over time.

POKT Inflation

As the number of Nodes grows in the Pocket ecosystem, if we assume a constant per-relay payout, it follows that the total amount of POKT generated by the nodes will increase. While POKT was designed to be permanently inflationary, the high rate of inflation which this situation causes has strong repercussions for the network itself.

There are plenty of benefits to inflation, such as attractive rewards for new and existing participants, near term buying pressure from new node runners, and the ability to bootstrap new chains more easily. And excitement in the marketplace driven by node rewards can lead to increased adoption.

However, there are many drawbacks to excessive inflation, such as sell pressure which may reduce activity on the network, network underutilization and unnecessary hardware costs, and a general perception of long-term unsustainability.

With this in mind, the DAO has voted on implementing and ongoing adjustment to the value of the rewards per relay (in parameter form, known as RelaysToTokensMultiplier).


For more information and to read the actual DAO proposals on inflation management, please see the following:

Inflation management

At the beginning of 2022, the DAO instituted an inflation management framework called the Weighted Annual Gross Max Inflation rate (WAGMI).

A WAGMI target of 100% was implemented on Feb 28, 2022, which corresponds to a per-node reward of 0.008461 POKT/relay. It was originally set to 0.01 POKT/relay.

WAGMI targets were stepped down to 50% over the following five months as follows:

DateWAGMI Target Inflation Rate
Feb 28, 2022100%
Mar 26, 202290%
Apr 25, 202280%
May 25, 202270%
Jun 24, 202260%
Jul 24, 202250%

The per-node reward (also known by its parameter value RelaysToTokensMultiplier is calculated using:

  • The 30-day trailing average of daily relays at the time of each adjustment
  • The total supply at the time of the proposal passing (“Total Supply Baseline”):
$$ \text{Mint rate} = \frac{\text{Total Supply Baseline} \times \text{Inflation rate}}{\text{30-day trailing average of daily relays} \times \text{365 days}} $$

The timestamp of the proposal was Feb 24, 2022, 6:37 GMT (block height: 51909), and the Total Supply Baseline was 945,014,989 POKT.

Further inflation management

Following the successful step-down to 50%, a new proposal, PUP-22, known as FREN (Further Reduction of Emission Numbers), determined additional alterations to the amount of POKT issued.

The proposal extends the reduction of the emission rate over an additional five months, starting with an immediate reduction of target emission to 1,000,000 POKT/day (down from approximately 1,300,000) with a goal of 690,000 POKT/day by the end of 2022 through periodic reductions in the RelaysToTokensMultiplier. This corresponds to an effective inflation rate of 26.8%, decreasing to 18.5%. The first of these reductions went into effect on September 1, 2022.

Reward recalculations by date

DateTarget inflation rateTarget daily emission rateApprox. 30-day trailing avg. of daily relaysMint rateRelaysToTokensMultiplier
Feb 24, 2022100%N/A306M0.0084618461
Mar 25, 202290%N/A311M0.0074987498
Apr 1, 202290%N/A403M0.0057765776
Apr 8, 202290%N/A481M0.0048474847
Apr 25, 202280%N/A693M0.0029882988
May 31, 202270%N/A860M0.0021092109
Jun 30, 202260%N/A879M0.0017681768
Jul 24, 202250%N/A945M0.0013711371
Sep 1, 202226.41%1,000,000963M0.0010381038
Oct 3, 202226.41%1,000,000928M0.0010771077
Oct 28, 202226.41%1,000,0001.20B0.000832832
Nov 8, 202223.24%880,0001.22B0.000719719

Pricing & Economics FAQ

What is POKT?

POKT is the native utility token that powers the economics of the protocol. Pocket Network requires both developers and nodes to stake POKT to participate in the network. Nodes earn POKT for fulfilling API requests for apps on a per request basis.

How much does it cost to send a relay?

This is determined by the BaseRelaysPerPOKT parameter.

How much can I earn by running a node?

Pocket is quite a unique blockchain network, because there are two ways for nodes to earn POKT:

  1. Servicing: processing requests to/from blockchains on behalf of apps
  2. Validating: confirming blocks, which contain proofs of the above relays done

Each time a block is validated, POKT is minted according to the RelaysToTokensMultiplier parameter which means, for every relay processed by a node, this amount of POKT is minted.

This mint is then divided according to the following percentages:

So what does this mean in practice?

Check out these charts to view the profitability of nodes over the lifetime of the network.

What is the minimum staking amount for a node?

The minimum staking amount for nodes is determined by the StakeMinimum parameter.

However, as a best practice, we recommend staking an extra 7% to 10% buffer of POKT above the minimum stake per node. This is to account for any unforeseen slashing events due to node misconfiguration, bad behavior, natural disaster, or potential accidents.

What determines my odds of being selected to validate a block?

The following formula:

round down (node stake / avg node stake) = # of tickets in the hat for block producer

Is there an advantage to staking all of my POKT on one node?

Yes, up to a point.

As of version 0.9.0, PIP-22 introduced Stake-Weighted Servicer Rewards. This implementation seeks to reduce the infrastructure costs for node runners by allowing for rewards to be generated roughly proportional to the total amount of POKT staked.

For example, if a node runner has four nodes with 15,000 POKT staked in each, the node runner could instead run one single node with 60,000 POKT and generate four times the previously-generated rewards for each relay served. Thus the node runner can reduce infrastructure costs by 75% while still generating the same rewards.

There is a limit to this benefit though, as determined by the DAO, beyond which, any additional POKT staked will not incur any benefit. This is managed by the ServicerStakeWeightCeiling parameter.

How do I buy POKT?

See the section on managing POKT.

What is the supply of POKT?

Genesis & Circulating Supply

The initial supply of POKT is 650M, which is divided according to the following genesis distribution:

The vast majority of these tokens are non-transferable and subject to use restrictions by the holders, starting from mainnet launch. __

  • Private Sale 1/2: one-year lockup and use restriction from the date of purchase. Those whose year had already expired pre-mainnet also agreed to an additional lockup according to the following schedule: 50% of tokens unlocked after 6 months, 100% of tokens unlocked after 12 months.
  • Founder Vesting: the founders agreed to restart a 3 year vesting schedule upon mainnet launch, with 10% of their allocations immediately vesting upon mainnet launch and subject to a 1-year lockup and use restriction. __
  • Pocket Network, Inc. (PNI):
    • Token Sale Pool: fully unlocked at launch and available for direct sale to users of the network. __
    • Employee/Contractor Pool: already-vested tokens subject to a 1-year lockup and use restriction, with varying vesting agreements per contractor on average of 3-4 years.
    • PNI Reserves: subject to 4 years of vesting and non-transferable for five unbonding periods (105 days total) following mainnet launch. __
  • Foundation/DAO:
    • Foundation Reserves: subject to 4 years of vesting and non-transferable for five unbonding periods (105 days total) following mainnet launch. __
    • DAO Funds: fully unlocked at launch and distributed according to DAO grants.
    • All other genesis addresses (e.g. incentivized testnet participants): non-transferable for five unbonding periods (105 days total) following mainnet launch.

This all results in the following circulating supply schedule:

Fully Diluted Supply

While the initial total supply of POKT is 650M, Pocket Network uses minting to compensate nodes for performing work on the network. For this reason, POKT is permanently inflationary proportional to usage of the network, i.e. proportional to the number of relays being processed by nodes, but the total supply will be capped through a burning mechanism put in place by the DAO (more on this below).

The Growth Phase of the network is characterized by relatively high rewards and an increase in the POKT supply designed to subsidize the bootstrapping of the network from a node and application perspective.

Once the growth rate of relays begins to decrease because Pocket Network has saturated the broader decentralized infrastructure market, Pocket Network will enter the Maturity Phase. It’s at this point that the DAO can choose to institute the Application Burn Rate (ABR) which burns developers’ stake at a rate that offsets future inflation - capping the total supply of POKT. The ABR caps the total amount of POKT and ushers in network equilibrium where mint and burn rate is equal. This is reflected in our model by a flattening in the growth in POKT. In all three scenarios, ABR is instituted at the same time but could happen earlier or later as the DAO sees fit.

You can read more about these topics in the section on Monetary Policy.

Future (v1)

Pocket Network launched on mainnet on July 28th 2020, with the singular goal of providing a utilitarian economy between Web3 applications and the full nodes that provide access to the data they need. Since launching, Pocket Network has demonstrated that a decentralized alternative to full node infrastructure is not only possible, but with the right architecture could provide a service that is unmatched. Further, the lessons we have learned maintaining the network have highlighted a path towards a truly scalable future for Pocket Network’s Web3 infrastructure. These are the possibilities that v1 seeks to achieve.

When we started working on Pocket Network, we were a scrappy startup with months of runway. For our vision to survive, we had to build our concept as lean as possible. This is where Tendermint Core came in, a general-purpose framework for building applications that require their own application specific blockchain. This provided us with the minimum viable networking and BFT consensus stack we needed to build a kickstart our vision. But, as we have grown, we have continued to push the limits of Tendermint’s general-purpose capabilities. We have made so many changes over the years that Pocket Network is now unrecognizable compared to the typical Tendermint ABCI application. These changes have allowed us to scale Pocket Network to the largest Tendermint network out there, exceeding 27,000 nodes while Tendermint was built to handle at most 10,000.

We have come to realize that, to reach our true vision of unstoppable Web3 infrastructure network with millions of nodes serving quadrillions of relays, we need to bid farewell to Tendermint and build our own stack from the ground up using all of the lessons we have learned after 1.5 years of mainnet optimized for Pocket’s use case.

v1 will contain 4 specialized modules that are optimized for Pocket Network’s core utility:

v1 will also be the catalyst for an enhanced engineering process that is more inclusive of the community, with robust laboratory infrastructure for responsive experimentation, QA, visibility, tooling and tighter development feedback loops. This is an R&D project with at least 1 year of work anticipated before the launch of v1.0 mainnet. We are revealing our vision to the community at this stage to empower everyone to get involved in our new development cycle:

  • You can follow along the R&D cycle in GitHub.
  • You can post your research ideas in the Pocket Forum.
  • You can chat about anything v1 in Discord.


Pocket Network has always been designed to do one thing and do it well: provide a utilitarian economy that coordinates unstoppable Web3 access. In the context of the v1.0 Utility Module, this means we are laser-focused on optimizing the existing utility of the network, not expanding the scope of our utility.

This means optimizing how effectively we coordinate Web3 access, which can be broken down into two categories:

  • Relay Quality: RPC node (Servicer) incentives should be as tightly-coupled as possible to relay quality, so that Pocket Network’s service not only matches centralized providers’ but provides a level of quality, unique to Pocket’s architecture, that can’t be matched
  • Relay Scalability: our protocol should be as scalable as possible, to maximize the number of relays that the network can process and optimize the efficiency (and thus cost) of the service

Relay Quality

Quality Enforcement

v0 – Client-side + Layer-2 Enforcement

When we first designed Pocket Network, we assumed that service quality would be ensured through a Darwinian competitive dynamic. Indeed, there is a weak incentive to perform better on latency/volume to maximize relays processed, though this is insufficient to ensure quality on all metrics.

To address this, we included a simple client-side validation mechanism known as a challenge transaction, which enables Apps to protest the rewards that Servicers earned for low-quality work. However, 1.5 years into mainnet, challenge transactions have never been utilized, likely since the Portal does quality checks before it sends relays. We’ve learned that client-side validation is an insufficient model to rely upon because it 1) results in Apps experiencing quality failures before they are corrected, 2) forces Apps to choose between validating relays and maximizing relay speed.

The Portal is our gateway drug. It is a web application that stakes Pocket Apps on behalf of developers, and allows us to provide the simple RPC endpoints that apps have come to expect from centralized providers. Currently, the Portal administers the majority of the protocol’s App stakes to ensure service quality while we bootstrap new chains. In 2021 we developed various layer-2 cherry-picking methods through the Portal to ensure that Apps receive service from the highest-quality Servicers available in each Session. These methods have laid the groundwork for the on-chain quality enforcement that we will be introducing in v1.0.

Utility v0 High Level Overview

v1.0 – On-chain Enforcement

The Portal is a service that builds on the Pocket Network, managing app stakes on behalf of Apps and providing quality of service checks. Maintaining this core service has shown us how critical quality assurance is to our core utility, so we decided to take these lessons and move them on-chain.

We have considered a world in which other people deploy their own Portals and compete to provide the best layer-2 quality enforcement. However, we realized that Portals would fall to the tragedy of the commons; they are simultaneously expensive to run and inherently altruistic. The only way this could be resolved off-chain is through economies of scale and extractive pricing. Sound familiar? If we went down this route, we would no longer be solving the incentive problem we saw in the full node ecosystem, we’d simply be pushing it further up the stack.

To solve this in a manner compatible with our trustless vision, the protocol needs to directly incentivize actors on-chain to enforce quality according to a standardized ruleset. Enter the Fishermen. These are a new set of actors who can disguise themselves as Apps and sample the quality provided by Servicers.

Fishermen measure the quality of relays across three key metrics according to a standardized sampling protocol:

  • Availability: Since Fishermen, Apps, and Servicers are all time-synced according to the session protocol, time-based sampling can be used to assess the availability of the Servicer. If no signed response can be collected from a Servicer, a null sample is recorded for the sample time slot. The more null samples the worse the Servicer’s availability score.
  • Latency: The time it takes for the Fisherman to receive a signed response from the Servicer (i.e. Round Trip Time) is another metric that is tracked. Due to normal variances in latency to be expected from the varying geographical distance between Apps and Servicers, these metrics are used to disincentivize high-average latency rather than explicitly rewarding the highest-performing Servicers.
  • Consistency: In addition to time-based sampling, it is mandatory for Fishermen to sample all Servicers in a session at once. The Fishermen can then compare responses and measure data consistency without needing their own comparative Web3 datasource.

The Fisherman sends sampling requests to all Servicers to collect data about all 3 quality metrics Fishermen compile these samples into test scores for each Servicer, which are averaged out across Fishermen over time, ultimately determining the proportion of block rewards that Servicers receive. Fishermen are not incentivized to influence test scores because they are paid based on the quantity and completeness of their reports, not the content of the metrics being reported.

Utility V1 High Level Overview

Quality Incentives

v0 – Quantity-based

89% of v0 block rewards are distributed to Servicers proportional to the volume of relays they served. This means Pocket Network’s incentives currently optimize for the quantity of work done, not the quality of work done.

v1.0 – Quality-based

v1.0 prioritizes quality over quantity; block rewards are distributed to Servicers according to the aggregate test scores submitted by Fishermen.

The total salary for Servicers is still proportional to the volume of relays performed on aggregate. However, this is divided between Servicers in proportion to their test scores. Each Servicer above the MinimumReportCardThreshold is eligible for an equal salary from the total pool for their RelayChain or GeoZone but has their allocation burned by the difference between their ReportCard% and 100%.

This diagram illustrates how service rewards are divided equally then burned by the difference between their ReportCard% and 100%, assuming a burn coefficient of 1.

These incentives enable Pocket Network to probabilistically guarantee a Service Level Agreement for applications.

Relay Scalability

Proving Relays

v0 – Pessimistic Proofs of Relays

v0 is pessimistic about proving work done; guilty until proven innocent. To validate the volume of relays they completed, Servicers must generate plasma merkle trees, store relay evidence, and create merkle proofs, which will then be validated by Validators, as part of a multi-step Zero Knowledge Range Proof.

This works very well as secure cryptography but it scales linearly because plasma merkle trees have O(n log(n)) space complexity, where n is the number of relays, and the branch must be included in every proof transaction. In practice, this means proofs get more expensive to process in proportion to relays, which contributes to higher CPU loads and longer block processing times.

If Pocket Network is to grow to serve quadrillions of relays, the relay proof lifecycle must be fundamentally restructured.

v1.0 – Optimistic Proofs of Samples

Work payments in v1.0 are optimistic, more like a salary compared to v0’s unit-based payments.

The total salary pool is still proportional to the volume of relays performed on aggregate. To determine the size of this total available reward, Fishermen probabilistically estimate volume using probabilistic hash collisions rather than counting up (and proving) every relay.

The Fishermen samples themselves are also optimistic. Fishermen only need to submit test scores on a pseudorandom schedule and only need to verify a single pseudorandomly selected non-null sample. Since the Fishermen (and Servicers) can’t predict which test scores will be submitted or which samples will need to be verified, the monitoring system remains a secure deterrent of bad behavior while avoiding the cost that would come from validating every test score.

We only need to submit a subset of test scores and prove a subset of samples By switching to an optimistic model, we reduce both the frequency and size of proofs, which should allow relays to scale exponentially rather than linearly.

Creating & Validating Proofs

v0 – Unified Actors

In v0, until recently, Validators and Servicers were bundled together. This meant that the scalability of Servicers was bound by Validators, for two reasons:

  • Validators are subject to the scalability of the BFT consensus algorithm, which is arguably the least scalable component of our protocol by design
  • Servicers are burdened with performing expensive Validator tasks, even though these aren’t necessary to perform Servicer tasks

We have already begun moving away from this model with the separation of Validators and Servicers in v0.7. Limiting Validators to the top 1,000 by stake has allowed our Servicer count to grow to almost 25,000 without impacting the health of our blockchain. v1.0 will take this a step further.

v1.0 – Task-based Specialization of Actors

We have already agreed that Servicers shouldn’t need to validate proofs. Taking this a step further, why should they need to prove their own work? In v0, Servicers must constantly store claims and proofs if they want to get paid, which presents a computational burden that distracts them from optimizing on their most important tasks: relaying RPC requests.

In v1.0, we are more explicitly separating actors according to their tasks. We are introducing the Fisherman, whose sole responsibility is to prove the quality of work done. This narrows the scope of Servicer work to just performing relays, which should make it cheaper to perform relays and thus dramatically enhance the efficiency of the network’s core task.

v1.0 Utility Roadmap

1. Proto-Fish

We will begin live-testing the Fisherman sampling methods in v0, using the Portal as a low-risk supervised environment.

2. Castaway

When v1.0 launches, we will begin with a single DAO-governed Fisherman. This will enable us to adopt all the benefits of v1.0, with the Fisherman actor being the only trusted actor in the network.

3. Fishermen

We will then transition to a multi-Fisherman model, wherein DAO governance can appoint and remove Fishermen, burning them to penalize bad behavior.

4. Cast-Net

Finally, Fishermen will become truly trustless actors as the monitoring/enforcement of their behavior is moved entirely on-chain.

More Details

Read more details about the v1.0 Utility module spec.


The consensus module coordinates Validators to come to agreement that the transactions in a block are legitimate before the block is added to the blockchain. Currently, v0 inherits its consensus implementation from Tendermint. While Tendermint provides a great framework for building applications that can handle arbitrary computation, it is not optimized for Pocket Network’s singular focus of coordinating unstoppable Web3 access.

Some of the major changes to the consensus module for v1.0 include:

  • Replacing Tendermint BFT with HotStuff BFT
  • Migrating from a Round Robin leader selection process to a blind, pseudorandom leader selection process
  • Allowing the Block Proposer to validate transactions against the mempool before including them in a block

For the network as a whole, these changes will enable more consistent block times. For those running nodes, these changes will allow for:

  • Less bandwidth and compute resources spent communicating with other nodes during consensus
  • Less storage usage, as invalid transactions will no longer be included in blocks
  • Block creation rewards proportional to the amount staked.

A Primer on Consensus

The two most popular types of consensus algorithms are Nakamoto and Byzantine Fault Tolerance (BFT).


In Nakamoto consensus, the network chooses to follow the longest chain. This is the consensus mechanism that Bitcoin, Ethereum 1.0, and most Proof of Work chains currently use. As long as someone can submit a valid proof of work, they can add a block to the chain.

In case the block added was fraudulent, whether maliciously or accidentally, whoever submits the next block can choose to do so from whichever point they wish, creating a fork in the chain. If the network adopts this new chain enough that it becomes the longest, this results in what’s known as a chain reorganization. This is why applications that make transactions on these chains often wait for a number of “confirmations”, because the chain can potentially reorganize at any point. This process of waiting for transactions accomplishes something called probabilistic finality.

Probabilistic finality works well for coming to consensus on events that have already occurred, however, since Pocket Network uses the current state of the blockchain to determine which Servicers to match Apps with, Nakamoto consensus is incompatible with the Utility module.


In BFT consensus algorithms, Validators must come to agreement before adding any blocks to the chain. The name comes from the “Byzantine generals problem”, a thought experiment that dealt with how a group of military generals, who could not communicate directly with each other, could come to a decision about whether to attack or flee. This issue doesn’t just deal with the case of the general being a malicious actor, but also the case of the messenger being the one who changed the vote, or simply not being able to deliver the message. In a computer system, Byzantine faults are used to describe errors that can occur from an actor either being compromised or faulty. These types of consensus mechanisms, while useful for blockchain consensus, were originally developed to enable aircraft to rely upon their sensor data to make software decisions as long as a certain threshold of their sensors were always in agreement.

Where Nakamoto consensus can probabilistically resolve fraudulent blocks through its longest-chain selection process, BFT instead opts to require consensus on the next block before moving forward with the chain. Since Pocket Network’s Utility module requires a single state from which to maintain coordination between Servicers and Apps, BFT is the obvious choice.

The Consensus Algorithm

v0 – Exponential Communication Complexity

The Tendermint BFT consensus algorithm has served Pocket Network well but will hold us back because communication complexity scales exponentially in proportion to the number of nodes, for two reasons:

  • Network-Wide Random Gossip: Every node in the network must pass on what every other node has told them, including Servicers. The more nodes there are, the more node-node messages must be sent and received, resulting in an exponential volume of messages. If Pocket Network is to continue scaling to hundreds of thousands of nodes, this gossip process must be fundamentally restructured, otherwise the communication bandwidth required will become insurmountable.
  • Pessimistic Responsiveness: When voting on a block, the network must wait for all nodes to vote (or wait a minimum period of time) before moving on, even if enough votes have already been cast to reach consensus. This can make the network more vulnerable to chain halts if not enough nodes can keep up with the voting process.

v1.0 – Linear Communication Complexity

We will be solving these issues in v1.0 by switching to our own implementation of the HotStuff BFT consensus algorithm: HotPocket. The biggest advantage of this algorithm is that it uses validator-specific structured gossip and optimistic responsiveness to significantly reduce communication complexity.

  • Validator-Specific Structured Gossip: HotPocket selects a small group of nodes to be responsible for listening for messages and then broadcasting gossip to everyone. This means instead of sharing messages with everyone, nodes only have to share with the selected listeners, which allows communication bandwidth to scale exponentially with the number of Validators.
  • Optimistic Progress: HotPocket introduces a new phase in the consensus process. During this phase, Validators must acknowledge that they have seen the block proposal going up for a vote. When it comes to the voting phase, any Validators who did not acknowledge the proposal can be dismissed and the chain can move on with majority consensus as long as the present Validators approve it. Along with this, we have a custom pacemaker module that ensures consistent block times, which are critical for the time-synced mechanisms in the Utility module.

The Leader Selection Process

v0 – Round Robin

Tendermint uses Round Robin to determine the next leader who will propose the next block. This makes the blockchain vulnerable to DDoS attacks since we know exactly who the next leaders are going to be and when. We have already modified Tendermint’s Round Robin to use a pseudorandom selection algorithm where the hash of the previous block determines the next leader.

v1.0 – VRF + CDFs

In v1.0, we are leveraging Verifiable Random Functions (VRFs) for more secure pseudo-random leader selection that is unpredictable before the block production, yet deterministic and computationally cheap to verify afterwards. Whereas v0 uses the previous block hash to generate leaders, v1.0 uses the VRF secret keys of other Validators which are impossible for the proposer to know. VRFs are combined with Cumulative Distribution Functions (CDFs) to enable selection to be weighted based on the amount staked by the Validator. Because it is probabilistic, it is possible for the VRF to generate 0 proposers, in which case we fallback to the v0 Round Robin process.

Handling Invalid Transactions

v0 – Block Proposer Can’t Validate

Since Tendermint was designed to support arbitrary computation, there were risks for them allowing the block proposer to validate transactions against the mempool. Since the state of the mempool changes as transactions come in, there is currently no way for the block proposer to know if transactions are valid before proposing them in a block. For chained and dependent transactions that rely on ordering, this can cause problems of unexpected failed transactions. Since transactions aren’t validated until they’re included in the block, this leads to the chain being bloated with meaningless failed transactions, which makes indexing and processing transactions harder, ultimately wasting resources.

v1 – Block Proposer Can Validate

Since Pocket Network isn’t a blockchain built for arbitrary computation, and instead built for a specific purpose, we can make guarantees about what computations would occur if the block proposer tried to validate transactions against the mempool. This means that it is possible for the block proposer to filter invalid transactions before proposing a block. This will greatly help to reduce the storage requirements of the chain as well as making it easier to index and process transactions.

More Details

Read more details about the v1.0 Consensus module spec.


The Peer-to-Peer (P2P) module is responsible for handling how all the nodes in the network communicate with each other when new transactions need to be added to a block and when the new block gets added to the chain. Currently, v0 pairs peers together randomly. This random pairing was chosen to ensure redundancy across the network, however, as Pocket Network continues to grow, the redundancy and complexity of random pairing require more bandwidth as more nodes come online – with a good chunk of that bandwidth being used to retrieve copies of information the nodes have already seen.

In v1.0, the P2P module will transition from random communication to structured communication. For those running nodes, this transition means a significant reduction in bandwidth usage. For the network as a whole, this means more efficient and scalable communication, while maintaining the required redundancy. This will move the P2P system from having low visibility and a large amount of message duplication to having high visibility and less message duplication.

A Primer on P2P

There are three primary components of the P2P system that all contribute to the reliability and speed of the network. Those components include Event Dissemination which handles how nodes will be paired to communicate with each other, Membership and Churn which handles knowing when nodes either come online or go offline, and the Transport Layer which controls the mechanism used to actually send and receive messages between peers. Some of these problems are problems that can apply to networking across the board, while others are unique to P2P networks specifically. The requirements of building an effective P2P communication network include:

  1. Efficiency and Scalability – making sure that more peers can connect without a major impact to the network performance
  2. Fault and Partition Tolerance – despite any number of breakdowns that happen between nodes, the network can continue to operate
  3. Managing Membership and Churn – effectively communicating when a peer both joins and leaves the network.

While there are a large variety of existing P2P implementations out in the wild, each implementation has made design decisions based on specific needs that don’t translate to the needs of Pocket. In choosing the design for the v1.0 implementation, it was important to understand the fundamental needs of Pocket Network. There are three types of communications that are fundamental to how Pocket Network operates.

  1. Servicers need to be able to inform the network of transactions made
  2. Validators need to be able to communicate with each other during consensus and with the whole network when a new block is created
  3. Archival nodes need to be informed of new blocks, as well as handling and making requests for new blocks.

From these three main types of communication, we can specifically say that the P2P module of Pocket Networks needs to be able to:

  1. Communicate blocks and transactions across the network
  2. Restrict communications to only the groups who are needed for those communications.

Event Dissemination

v0 – Random Gossip

Currently, Pocket Network communicates information about blocks and transactions through random gossip. When a node learns of a new piece of information, they pass that information along randomly to other nodes in the network. This random process ensures that the data can make its way through the network, regardless of failures between certain pairs of nodes. This process, while ensuring redundancy, does so in a way that requires nodes to spend bandwidth and resources receiving the same message multiple times.

Building on this, because nodes randomly select other nodes to share this information with, nodes will share and receive information regardless of whether that is information they need. Gossip about the consensus process is only relevant to nodes who are acting as Validators. Gossiping with every Servicer and Archival node about the validation process not only takes away resources from those nodes but it slows down the gossip phase of the consensus process.

v1.0 – Structured Gossip

RainTree is a gossip protocol that leverages the efficiency that Binary Trees provide for lookups of sorted, randomly-distributed data. RainTree provides the mechanism to ensure delivery, offer redundancy against non-participation without needing retries or acknowledgements, and perform a cleanup to ensure 100% message propagation in all cases.

The process starts with a node that wishes to gossip a message to all other peers in the network. Once the node has a sorted list of all other peers in the network, it needs to:

  1. Build a binary tree based off the sorted list, with the left branch being the peer at 33%, and the right branch being the peer at 66%, with a third branch that points back to itself
  2. Determine its own and max depth of the tree
  3. Gossip messages to all depths of the tree.

The peers on the left and right branches then build their own subsections of the tree using the above, and the process continues. This third branch is there to add redundancy. When the node begins gossiping down the tree, it will, eventually, reach the point where it has to send itself the message. Once it has reached this point, the node is able to send it to not just the left and right as expected but also every other node in the originally sorted list.

Since networks are vulnerable to nodes dropping out at any point, if one of the branches does not acknowledge that it received the message, the node that tried to communicate with them will then readjust and send the message to the children that would have received the message from the unresponsive parent.

A successful transmission to the left and right nodes. An unresponsive right node means that the children of that node need to be notified directly To be 100% certain that all functional nodes received the message, the Double-Daisy-Chain (DDC) cleanup layer provides a reliability mechanism that’s used in other gossip algorithms, including epidemic communications. Once the message propagation has reached the next to last layer of the tree, the nodes in the final layer are sent a special “I Got You Want?” (IGYM) message that expects either a Yes/No answer. If the answer is a Yes, the node is forwarded along the full message and they continue said process. If the answer is No, or there is no answer, that node is skipped and the next node in the chain is selected for the same process.

DDC Cleanup Layer

Gossip Restrictions

v0 – Everyone Communicates Everything

In the current system, all nodes communicate any information to all other nodes regardless of whether the information is relevant to that node. This means that Servicers must actively listen and share information about the consensus process, despite the fact that they are not participating. In networks that primarily consist of Validators, this doesn’t cause many issues, but since Pocket Network contains other specialized actors such as Servicers and Fishermen, scaling these actors should not impact the communication of processes irrelevant to their input. If we don’t scale actor communication independently, scaling Servicers and Fishermen will slow down consensus, resulting in longer block times.

v1.0 – Restricted to Relevant Parties

The gossip protocol in the Consensus module is a specialized version of RainTree designed for that specific case. As Pocket Network already keeps a list of the current Validators, it’s possible to leverage RainTree for this process. This allows the consensus process to take advantage of the optimizations and redundancy of RainTree. Even more importantly, since the tree will be constructed from only the list of Validators, this means that gossip related to consensus can occur only between those that are involved in the process. This means that the consensus process isn’t held up by trying to communicate with the entire network and that other actors are now unburdened from gossip that isn’t relevant to them.

More Details

Read more details about the v1.0 Peer To Peer module spec.


The Persistence module is responsible for ensuring that the data continues to persist over time, across deployments, and throughout software changes. Currently, V0 handles data persistence through Tendermint. Tendermint uses a similar mechanism to most other blockchains, storing the different state data that needs to persist in Merkle trees. The roots of these trees are included in the block, and then for each block, each of the trees is stored as a file.

This design simplifies the computational overhead a new client would need to get up to sync with the current block, however, it does so at the cost of storage. While this decision was made to ensure that the barrier to entry of acting as a validator of a network is low, it fails to consider how critical full nodes, nodes that maintain copies of the data to be accessed and queried by applications, are as infrastructure for production applications.

As the core mission of Pocket Network is to provide access to high quality, decentralized infrastructure, the role of the full node needs to be considered as a priority and not an afterthought. Some of the changes that are being made to the persistence layer in V1 include:

  • Moving from a Key Value Filesystem DB to an SQL based Tamper Proof Hybrid Mutable DB
  • Decoupling the persistence layer to allow for a Client Server Architecture between pocket-core and persistence.

For those interacting with the network, these changes will mean significantly faster access to any state data that would have relied on a query to access.

For those running nodes, these changes will not only make the current experience better, but it will also open the door to more control and options when it comes to deployment configurations. These changes will:

  • Drastically reduce the storage needs (80%) for storing the blockchain data.
  • Drastically reduce the amount of resources needed to query state data. (10+ seconds -> milliseconds)
  • Enable better data portability, making it easier to quickly spawn up additional databases as needed
  • Enable individual scalability, making it easier to kill off and replace a failed process.
  • Allow for an additional layer of fault tolerance, since the choice for database engine can be replaced.
  • Enable for multi-process concurrency, making it possible to horizontally scale pocket-core without worrying about the storage cost for doing so.

Underlying Database

V0 – Key Value Filesystem

Currently, at each block, the data that represents the current state is stored as a tree in a file. While this provides some benefits, such as being able to simply move a directory to move the data, and easily being able to store arbitrary data, these benefits come with significant downsides. For one, regardless if anything has changed in the state between blocks, an entire copy of that tree is written again. There is no process for currently managing data deduplication.

The other issues come from using a filesystem as a production database. Out of the box, Linux cannot handle the amount of simultaneously open files needed to manage a system in this manner, hence needing to make sure the ulimit is properly specified before running a node. Using the filesystem also means that data access is almost entirely reliant on the I/O speeds of the system. When you add in how querying through old state would mean opening multiple files, this means that queries dependent on I/O are the slowest part of the system.

V1 – Tamper Proof Hybrid Mutable DB

SQL provides a mature, optimized, battle-hardened solution to the data storage problem. One issue with SQL is it requires a well-defined data schema, and so it’s well suited for arbitrary data storage. Since Pocket Network does not handle arbitrary computation, and instead serves a defined application specific purpose, SQL provides the opportunity for significant storage and speed optimizations.

A Persistence Client Middleware will communicate between pocket-core and a generic database engine, to define what needs to happen to define, persist, update, and query the datasets it stores. This mechanism will define the following to ensure consistency:

  1. Versioning of the state dataset
  2. Byte-perfect consistency of the data encoding
  3. Schema definition mechanism
  4. Deterministic write mechanism
  5. Idempotent Dataset Updates

To ensure that the data is tamper proof, the Patricia Merkle Tree can be stored in the state dataset for each block, and can be used to verify the validity of each block. As the operations on the data are ACID and idempotent, any change to the underlying data is detectable.

System Deployment

V0 – Data Duplication

The current system requires that each pocket-core process needs access to an independent copy of the data to run. If a node needs to increase resources, whether that be to handle more traffic, or more data access, the only option is to start another process that needs a full copy of the data to run.

V1 – Client-Server Architecture

Breaking the core and persistence layers into a client server architecture gives node runners the ability to scale and manage the respective processes more efficiently. While keeping the persistence layer on the same machine as the pocket-core process would allow for the least latency, it also restricts the node runner from configuring their infrastructure in a way that best serves the needed demand.

Some of the examples that node runners now have access to include:

  • Spawning up multiple pocket-core processes on behalf of the same identity to scale to handle more demand.
  • Connecting multiple pocket-core processes that represent at least two nodes in close physical proximity to the same database.
  • Connecting multiple pocket-core process that represent multiple nodes to a database cluster to allow a collection of nodes to efficiently scale-up storage needs

Some example deployment configurations available when allowing for a Client Server architecture Since nodes know the maximum amount of relays that the applications it’s serving can request, this gives node runners the ability to save costs by allocating resources only as needed.

More Details

Read more details about the v1.0 Persistence module spec.

Protocol Parameters

This page contains a listing of all the on-chain parameters for Pocket Network, as well as their current values.

These parameters are sorted by module.

Application Module

These parameters control staked applications on the network.


Current Value: 1000000

The minimum stake required of an app, denominated in StakeDenom. This does not have the same economic security requirements as a node’s minimum stake because an app’s access to the network (relay throughput) is already proportional to the stake.


Current Value: 1814000000000000

The time, in nanoseconds, that an app must wait after initiating an unstake before they can use the POKT for anything else.


Current Value: 200000

The number of relays that an app is entitled to for every POKT it stakes, multiplied by 100.

For example, if this parameter is 200000 then the throughput that apps are entitled to is 2,000 relays per POKT staked.


Current Value: 2295

The number of staked applications that the protocol allows.


Current Value: 15

An app can only be configured for up to this many chains on one stake.


Current Value: false

The protocol may adjust an application’s MaxRelays at the time of staking according to network-wide stake rates.

The ParticipationRate is a proposed tool to dynamically adjust maximum relays for applications without the intervention of the DAO as network usage changes. ParticipationRate would act as a proxy for utilization of the network and would adjust an application’s MaxRelays dynamically based on the growth or decline in network-wide stake rates.

The ParticipationRate is not currently implemented, and as such, ParticiapationRateOn is set to false.


Current Value: 0

The DAO may manually adjust an application’s MaxRelays at the time of staking to correct for short-term fluctuations in the price of POKT. When this parameter is set to 0, no adjustment is being made.

PoS (Node) Module

These parameters relate to staked nodes on the networ, including how rewards are calculated.


Current Value: 4

The number of blocks allowed before a Session tumbles.


Current Value: 10

The DAO treasury earns this proportion of the total POKT block reward. Value is a percentage. See also ProposerPercentage for another beneficiary of the block reward.


Current Value: 3600000000000

The amount of time (in nanoseconds) before a node can unjail and resume service.


Current Value: 120000000000

The amount of time (in nanoseconds) a node has to submit their Tendermint evidence in memory before it expires.


Current Value: 15

A node can only be configured for up to this many chains on one stake.


Current Value: 37960

The amount of time (in blocks) a node has to unjail before being force unstaked and slashed.


Warning: Reaching MaxJailedBlocks will result in a node’s entire stake being slashed.


Current Value: 1000

The number of staked nodes that are eligible to be selected for producing blocks. Any staked nodes outside of the top MaxValidators staked validators will still be eligible to service relays.


Current Value: 0.6

The minimum proportion of the SignedBlocksWindow that a node must sign to stay out of jail.


If SignedBlocksWindow is 10 and MinSignedPerWindow is 0.6, this means a node can miss up to 4 blocks out of every 10 blocks before it is jailed.


Current Value: 5

Block proposers earn this proportion of the total POKT block reward. Value is a percentage. See also DAOAllocation for another beneficiary of the block reward.


Current Value: 719

The amount of POKT, denominated in StakeDenom, that is minted as block rewards per relay.

Note that this value will change over time. Please see the section on POKT inflation for more information.


Current Value: 15000000000

The “width” of a bin (in uPOKT) used when organizing nodes for Stake-Weighted Servicer Rewards.

All nodes with an amount of POKT staked that is both greater than the StakeMinimum and less than the value of this parameter will have the same reward multiplier. Nodes in subsequent multiples of this parameter (up to and including the ServicerStakeWeightCeiling) will have additionally higher reward multipliers.


Current Value: 1

Determines how rewards scale for each bin used when organizing nodes for Stake-Weighted Servicer Rewards.

A value of 1 will cause the reward multiplier of the bins to scale linearly. Values greater than 1 will lead to higher bins having a non-linear greater reward multiplier, while values less than 1 will lead to higher bins having a non-linear lower reward multiplier.


Current Value: 60000000000

Denotes the minimum value (in uPOKT) of the top bin, used when organizing nodes for Stake-Weighted Servicer Rewards. Any node with an amount of staked POKT at or above this value will have the highest available reward multiplier. Staking any more POKT will not incur any greater rewards (except as a Validator).


Current Value: 1.734

Offsets the increased reward emissions generated due to Stake-Weighted Servicer Rewards.

If the DAO determines that the amount of rewards generated is higher than desired, this will be set to an amount such that the reward multipliers of each of the bins are proportionally scaled down.

This parameter will likely change often due to its role in managing inflation.


Current Value: 10

The number of consecutive blocks within which the MinSignedPerWindow proportion of blocks must be signed by a node to stay out of jail.


If SignedBlocksWindow is 10 and MinSignedPerWindow is 0.6, this means a node can miss up to 4 blocks out of every 10 blocks before it is jailed.


Current Value: 0.000001

The % of a node’s stake that is burned for double signing, where 1 is 100%.


Current Value: 0.000001

The % of a node’s stake that is burned for downtime, where 1 is 100%.


Current Value: upokt

POKT amounts are defined by the protocol. Read more about POKT denominations.


Current Value: 15000000000

The minimum stake required of a node, denominated in StakeDenom, for the economic security of the protocol.


Current Value: 1814000000000000

The time, in nanoseconds, that a node must wait after initiating an unstake before they can use the POKT for anything else.

Pocket Core Module

These parameters control the logic that has to do with how the proof and claim cycles for servicers operate.


Current Value: 24

The amount of time (in blocks) a node has to submit a proof for an already existing claim.


Current Value: 3

The window of time (in Sessions) a node can submit a claimTx for RelayEvidence collected in the most recently ended session, before the claimTx expires. In addition, it is also the minimum amount of time a node must wait to submit a proof for an existing claim.


Current Value: 10

The minimum number of relays a node must have for a claim and proof to be payable.


Current Value: 3

The multiplier slash factor for submitting a replay attack. The base slash is directly proportional to the amount of relays claimed.


Current Value: 24

The number of nodes an app will be matched with in a session.


List of the RelayChainIDs for all of the supported blockchains.

Auth Module

These parameters control how transactions are constructed.


Current Value: 1

The multiplier factor for each transaction type. The base transaction fee is universally set at 10,000 uPOKT.


Current Value: 75

The character limit of transaction memos.


Current Value: 8

The maximum number of signatures that a multi-sig account can have.

Governance Module

These parameters control governance on the Pocket Network.


Access control list for updating the on-chain parameters. Currently all parameters are owned and managed by the DAOOwner address.


Current Value: a83172b67b5ffbfcb8acb95acc0fd0466a9d4bc4

The account which has the permission to submit governance transactions on behalf of the DAO.


Current Value:

  • Height: 74616

  • Version:

  • OldUpgradeHeight: 74540

  • Features:

    • MREL: 69232
    • NCUST: 74620
    • REDUP: 57620
    • RSCAL: 69232

An object describing the details of a protocol upgrade, consisting of the following fields:

  • Height: Specifies when the upgrade was applied
  • Version: Version that the upgrade brought
  • OldUpgradeHeight: Block height when the previous upgrade was last applied
  • Features: List of feature flags and the block heights at which they should be activated

Off-Chain parameters

These parameters are not on-chain, but are relevant off-chain values that are targeted by the Pocket DAO.


Current Value: $0.00000361 per relay

The target price per relay after a certain amount of usage (equal to the ReturnOnInvestmentTarget. After usage for this amount of time, your cost per relay will equal this amount. This parameter is set by the DAO.


Current Value: 24 months

The desired time it takes for the USDRelayTargetRange price to be achieved, since the cost basis of a relay decreases over the lifetime of an app stake.



Computer program that needs to read data from and/or send transactions to an external blockchain. Applications stake POKT into the Pocket Network Protocol in order to gain read/send access to the independent blockchain(s) that they need.

Applications are paired with groups of independent blockchain service providers, selected from Pocket’s decentralized network of thousands of service nodes. Applications can submit relays to the Servicers in this group to perform the needed read/send operations.

Application Authentication Token (AAT)

An Application Authentication Token (AAT) is needed for each client to authorize the use of an allocated “throughput”.

Application Authentication Tokens are similar in function to JSON Web Tokens (JWT) and provide security guarantees for the use of the service.

An AAT is generated after a client acquires & stakes POKT for an Application.

There are two design patterns recommended for AAT usage:

  • Optimizing for Safety: __ A simple server that distributes signed AAT’s using the clients Pocket Account. Though this pattern is of higher effort for the Application, it provides the highest security guarantee around their AAT
  • Optimizing for Performance: Embed a token production system within the Application code. This guarantees the smoothest UX for the clients and easiest setup for the Application. However, reverse engineering a source code level token generator can be trivial if obfuscation methods are not applied. The upside to this approach is not having the need to have an additional component in the Application that generates the AAT dynamically while keeping the Application private key secure.

Application Burn Rate (ABR)

Proposed mechanism that would burn developer’s stakes based on Application usage, and at a rate that offsets future inflation of the POKT cryptocurrency. Implementing ABR could help cap the total amount of POKT and promote network equilibrium where mint rate and burn rates are equal. For more information, see Monetary Policy.

Block Hash

SHA3-256 hash of a Block.


In the Pocket Portal, a URL that can receive RPC requests to a blockchain. Pocket allows you to “mint” endpoints that can be used with any of its supported blockchains. An Application can contain multiple endpoints (for multiple chains).


Situation where a Pocket node is denied the ability to serve relays.

A node can be jailed for one of two reasons:

  1. A node is not actively participating in consensus, for reasons such as being offline. More technically, this may occur if the node fails to produce min_signed_per_window amount of blocks over a signed_blocks_window. When jailed because of this reason, a node is Slashed a slash_fraction_downtime% of their Stake.
  2. A node “double signs” a block. Double signing is when a Validator node submits multiple signatures for the same block, which makes it more difficult for the network to come to consensus. When jailed because of this reason, a node is Slashed a slash_fraction_double_sign% of their Stake.

When a node becomes jailed, it remains in the Staked list of nodes, however it becomes ineligible to be selected for block production or to participate in Sessions. In order to become unjailed, the node must wait downtime_jail_duration nano-seconds, and then submit a Node Unjail transaction, which must then be approved.

If a node is left jailed for max_jailed_blocks blocks, it will be Force Unstaked.


Pocket Ecosystem Proposal. This is submitted to the Pocket DAO to distribute funds to or form agreements with contributors to the Pocket Network ecosystem. PEP categories include: Imbursements, Reimbursements, Bounties, Transfers, and Agreements. Each PEP is given a unique number as a suffix (such as PEP-13).


Pocket Improvement Proposal. This is submitted to the Pocket DAO to upgrade any facet of Pocket Network, including protocol and governance updates. Each PIP is given a unique number as a suffix (such as PIP-11).


Native cryptocurrency that underpins Pocket. Node runners stake POKT in order to earn rewards (also in POKT) from servicing relays from apps that utilize the Pocket Network. For example: “If you stake a Pocket node, you can earn POKT for every successful relay.”


A browser-based interface where developers can create (“mint”) a Pocket endpoint for use in their applications, utilizing a generous free tier of relays and scaling up as needed. Portal users can also monitor network performance.

Portal ID

Unique identifier for a collection of endpoints generated by the Pocket Portal. It is included as part of the URL of each endpoint.

Private RPC

RPC server that requires credentials for access.

Public Key

Unique identifier for a given Application that will allow you to inspect the Application on-chain.

Public RPC

RPC server that is accessible to the network without requiring credentials for access.


Parameter Update Proposal. This is submitted to the Pocket DAO to change the value of a given protocol parameter, either on-chain or in various tools or platforms. Each PUP is given a unique number as a suffix (such as PUP-11)


Blockchain API request and response transmitted through the Pocket Network.

A Relay Request is broken down into 3 sections:

  • Request Payload
  • Metadata
  • Proof (of Relay)

A Relay Response is broken down into 2 sections:

  • Response Payload
  • Servicer Signature

Requests are signed by the client of the Application and responses are signed by the servicing Validator.

This one-to-one signature scheme enables the protocol to validate all parties that participate in the servicing cycle.

Relay Chain

Database instance, typically a blockchain, provided by a Servicer node to serve Applications. Also can refer to both the database and the client that keeps the database updated and can accept read/send operations to that database.

Relay Evidence

Provable evidence of a Relay completed, backed by digital signatures from an Application client.


On-chain parameter that signifies the amount of POKT that is awarded to a node for a single successful relay. This value is periodically adjusted in line with Pocket Network’ monetary policy.

Remote Procedure Call (RPC)

Standardized process where one computer on a network is able to send a request to another computer on the network, to execute a command as if it were called locally from the computer. Many blockchains communicate by means of RPC.

Secret Key

Security feature for Applications created in the Pocket Portal. If “Private Secret Key Required” is selected in the Pocket Portal, then the Secret Key will need to be sent along with the request using HTTP Basic Authentication.


Any node which is eligible to serve RPC requests for Applications. By default, a node is a Servicer.


The endpoint that Servicers expose to provide Applications the functionality they need to send relays via the Pocket Network RPC to said Servicer.


A data structure which uses data from the finality storage layer of the network to pseudo-randomly group one Application with a set of nodes to provide service for a limited time. A Session lasts for 4 blocks, for a total of one hour.

Every Application will only have one single Session per relay chain it is staked for. Meaning, following an Application stake event, there will always be a corresponding Session for the Application for each relay chain until it unstakes.

List of Servicers that an Application is able to send requests to for a period of time. The Pocket blockchain periodically updates the Sessions so Applications receive a new, pseudo-randomly selected set of Servicers every four (4) blocks (determined by the BlocksPerSession parameter), or approximately one hour, for each Relay Chain that the Application is staked for. During this period of time, the Servicers will only be rewarded POKT for servicing Applications if they have been matched in a Session. The amount of Servicers in a Session is currently 24 (determined by the SessionNodeCount parameter).

Session Block

Some number of blocks, marking Session beginning/ends.


A feature that lets you connect to the same node for a set period of time. With stickiness all the relays are sent to the same node, ensuring more consistent relays.


Achievement earned for proving knowledge of and participation in the Pocket Network ecosystem. These can be collected and used to earn a vote in the Pocket DAO. There are four distinct paths to a vote, each with different trophies: App Developers, Node Runners, Community Shepherds, and Governors/Contributors.


Current active iteration of the Pocket protocol. Often used in contrast to the upcoming v1 update.


Pocket v1 (or just “v1”) is a major planned overhaul of the Pocket Network protocol, including a departure from Tendermint. v1 will allow Pocket to build its own network from the ground up, optimized for its specific use case, rather than being restricted by any limitations that come with building on Tendermint. v1 will bring major changes to four different “modules”: Utility, Consensus, Peer-to-Peer, and Persistence.


Special nodes that are responsible for committing new blocks in the blockchain, in addition to Servicing. Validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each Validator’s private key.

Validators stake POKT into the protocol to participate in Servicing and Consensus, just like Servicers, but because they are able to be block proposers, they can earn a slightly higher reward amount, as determined by the ProposerPercentage parameter.

Only the top 1,000 Servicers ordered by total POKT staked are considered Validators.


Weighted Annual Gross Max Inflation (WAGMI) is an inflation control mechanism for the Pocket Network that was established via PUP-11, and further defined via PUP-13. Together, these proposals established a target annual inflation rate, or WAGMI rate, in POKT, from which the RelaysToTokensMultiplier parameter (which determines the amount of POKT earned per relay serviced) is adjusted dynamically. The proposals also laid out a step-down in target inflation rate from 100% to 50% over a period of time.

Whitelisted Chains

In the Pocket Portal, an exclusive list of the blockchains that an Application can connect to. For example, if four chains are whitelisted, there will be four endpoints generated in that Application.

Whitelisted Contracts

In the Pocket Portal, an exclusive list of smart contract addresses that can access an Application endpoint. Note that this is only available for EVM-compatible chains.

Whitelisted Methods

In the Pocket Portal, an exclusive list of smart contract methods that can be used when accessing an Application endpoint. Note that this is only available for EVM-compatible chains.

Whitelisted Origins

In the Pocket Portal, an exclusive list of the HTTP Origin request headers that are allowed to make requests to the endpoint.

Whitelisted User-Agents

In the Pocket Portal, an exclusive list of HTTP User-Agent request headers that are allowed to make requests to the endpoint.


Wrapped POKT (wPOKT) is a proposed ERC-20 token backed by the native POKT cryptocurrency on the Pocket Network blockchain. Wrapped POKT would standardize POKT to the ERC-20 standard, enabling better interoperability, greater liquidity, and access to smart contracts.

Wrapped POKT is not anticipated to be launched until after the release of the new Pocket v1 architecture.