Pocket Network is the TCP/IP of Web3 node infrastructure – a multi-chain relay protocol that incentivizes RPC nodes to provide DApps and their users with unstoppable Web3 access.
Pocket supports dozens of blockchains, with more being added all the time.
Using Pocket Network is as easy as any other RPC. If you’re already using a centralized RPC provider, the Pocket Portal will be a familiar interface, and is where we recommend everyone get started.
Pocket can be made to work with any network/blockchain (RelayChain) that uses the RPC standard.
Current RelayChains
The following table shows the full list of supported, reward-generating RelayChains. This list should be identical to the SupportedBlockchains parameter.
Name
Portal API Prefix
RelayChainID
Arbitrum One
arbitrum-one
0066
AVAX
avax-mainnet
0003
AVAX Archival
avax-archival
00A3
BOBA Mainnet
boba-mainnet
0048
Binance Smart Chain
bsc-mainnet
0004
Binance Smart Chain (Archival)
bsc-archival
0010
Celo Mainnet
celo-mainnet
0065
DFKchain Subnet
avax-dfk
03DF
Dogechain Mainnet
dogechain-mainnet
0059
Ethereum Mainnet
eth-mainnet
0021
Ethereum Mainnet Archival
eth-archival
0022
Ethereum Mainnet Archival with trace calls
eth-trace
0028
Ethereum Mainnet High Gas
ethereum-mainnet-high-gas
0062
Evmos Mainnet
evmos-mainnet
0046
Fantom Mainnet
fantom-mainnet
0049
Fuse
fuse-mainnet
0005
Fuse Archival
fuse-archival
000A
Gnosis Chain Mainnet
gnosischain-mainnet
0027
Gnosis Chain Archival
gnosischain-archival
000C
Goerli
eth-goerli
0026
Goerli Archival
goerli-archival
0063
Harmony Shard 0
harmony-0
0040
IoTeX Mainnet
iotex-mainnet
0044
Kava Mainnet
kava-mainnet
0071
Kava Mainnet Archival
kava-mainnet-archival
0072
Klaytn Mainnet
klaytn-mainnet
0056
Kovan
poa-kovan
0024
Meter Mainnet
meter-mainnet
0057
Metis Mainnet
metis-mainnet
0058
Moonbeam Mainnet
moonbeam-mainnet
0050
Moonriver Mainnet
moonriver-mainnet
0051
NEAR Mainnet
near-mainnet
0052
OKC Mainnet
oKc-mainnet
0047
Oasys Mainnet
oasys-mainnet
0070
Oasys Mainnet Archival
oasys-mainnet-archival
0069
Optimism Mainnet
optimism-mainnet
0053
Osmosis Mainnet
osmosis-mainnet
0054
Pocket Network Mainnet
mainnet
0001
Polygon Matic
poly-mainnet
0009
Polygon Matic Archival
poly-archival
000B
Polygon Mumbai
polygon-mumbai
000F
Polygon zkEVM Mainnet
polygon-zkevm-mainnet
0074
Ropsten
eth-ropsten
0023
Scroll Testnet
scroll-testnet
0075
Solana
solana-mainnet
0006
Starknet Mainnet
starknet-mainnet
0060
Starknet Testnet
starknet-testnet
0061
Sui Mainnet
sui-mainnet
0076
Swimmer Network Mainnet
avax-cra
03CB
Velas Mainnet
velas-mainnet
0067
Velas Mainnet Archival
velas-mainnet-archival
0068
Pocket Testnet RelayChains
The following table shows the full list of currently-supported blockchains on the Pocket Testnet.
Name
RelayChainID
Ethereum Goerli
0020
Ethereum Rinkeby
0022
Ethereum Ropsten
0023
Pocket Network Testnet
0002
Adding a New RelayChain
Pocket Network is expandable, and is continually adding support for new chains.
Individuals interested in bringing a new RelayChain to Pocket Network are encouraged to advocate for chains to be considered by reaching out on Discord and posting a suggestion to our team. Join our Discord.
In order for a RelayChain to be successfully deployed with Pocket, the node running community will need to support the chain. So a chain that is easier to deploy, sync, and maintain, has helpful documentation, and provides stable nodes, will all tend to increase the likelihood of the chain being approved. Pocket Network aims to give the community of node runners sufficient notice to deploy their nodes with that chain to ensure a level playing field before making a determination to support the chain.
Once the determination has been made to support a new RelayChain, the RelayChainID will be added to the SupportedBlockchains parameter, meaning that nodes will earn POKT for every request that they relay for the RelayChain based on the RelaysToTokensMultiplier parameter.
Pocket Network Portal endpoints are designed to be compatible in any
web3 library or environment that access an RPC URL. This means that
getting up and started is a simple 2 step process.
Step 1 – Get an Endpoint
The first step to getting started using Pocket Network is to sign up for the
Portal, create an application, and get the endpoint for the
chain(s) that you need access to.
Head over to the Get an Endpoint page for full
details of this process.
Step 2 – Plug it into your Application
There are many different reasons why a developer would need to access
a blockchain in their application. Your Portal URL is designed to work
directly in some of the existing frameworks and libraries that different
developers would be interacting with.
UI and Interface Developers
If you’re building an interface to blockchain applications, a collection of
examples of how to use your Portal endpoint is available under Popular
Libraries.
Smart Contract Developers
If you’re a smart contract developer needing access to live chains in your
development environment, a collection of how to of examples of how to leverage
your Portal endpoint can be found under Smart Contract
Environments.
Interacting Directly with the Chain
If you’re looking to access blockchain data directly, but aren’t using a
framework or library, head over to our interactive API
Documentation to see how to interact directly with the
underlying blockchain API, either directly in your browser with your Portal
endpoint, or through the code samples provided for each of the different
supported requests.
Get An Endpoint
In order to take advantage of Pocket’s network of thousands of decentralized nodes, you need to get an endpoint that you can use in your application.
You can create your own using the Pocket Portal.
The Pocket Portal is a gateway to a decentralized RPC network, where developers can create (“mint”) blockchain network endpoints for use in their applications. Portal users can also monitor network performance and configure custom security features around their endpoint.
In this way, the Pocket Portal provides similar functionality to more centralized API services, all while retaining the decentralization that Pocket Network is built on.
The Portal has two usage tiers, an Always Free tier that allows for up to 250,000 relays per day, and a Pay As You Go tier that also offers relays beyond that with a nominal fee.
Once you create an account with one login method, you can’t switch to another method with that account, so make sure you choose the method that works best for you.
Click Get Started at the bottom of the page. Alternatively, you can click Sign Up at the top right.
On the sign up page, enter your email address and a password. When done, click Continue.
Info
Your password must contain at least 8 characters, and at least 3 of the following character types: lower case letters, upper case letters, numbers, and special characters. If your password does not meet these requirements, the failing criteria will be displayed on the screen.
On the next screen, click Accept to authorize the app to allow access to your newly-created account.
You will then be sent a verification email to the address you entered above. Open this email, and click Confirm Email Address.
Info
When you click this link, you will be taken to the main Portal homepage. You will know that verification succeeded because you will receive a subsequent email confirming your registration.
You can now log in. Click the Log In button and you will be taken to the Login page. Enter your credentials as previously given and click Continue.
Once you’ve logged in, you’ll be taken to the Network page (also known as the Dashboard).
Network Summary
In this section, you’ll see all the important parts of the Pocket network: how many nodes are staked on the network, blockchains supported, number of relays served over time, latest block details, and much more.
To search for a specific chain and its details, the Available Networks section has a search box where you can type in the name of a chain you would like to see.
Apps and Endpoints
Your Portal account is organized into Applications (Apps), which are subdivided into Endpoints.
An App is a project or container that allows you to view network throughput and relays across multiple blockchains.
An Endpoint is the RPC URL that connects to a specific blockchain via Pocket’s network of decentralized nodes.
Your account can contain a maximum of two Apps, and each App can contain any number of Endpoints for any number of chains.
Usage Tiers
Pocket Portal allows you to have 250,000 blockchain relays per App daily, absolutely free.
For many users, this is probably all you need. For others, especially with production-ready apps, you may wish to have more usage on-demand.
With both of these cases in mind, Pocket Portal offers two tiers: Always Free and Pay As You Go.
Always Free: Provides 250,000 relays per App per day, through any combination of Endpoints.
Pay As You Go: Also provides the same 250,000 relays per App per day, through any combination of Endpoints. However, should your App request more than this in a day, you will be charged a per-relay usage fee.
You can always switch between tiers. If you are hitting your limits in the Always Free tier, you can Upgrade to the Pay As You Go tier. And if you don’t need or want the extra daily relays, you can downgrade to the Always Free tier.
Info
The Portal has overflow protection in case an App in the Always Free plan accidentally goes over 250,000 relays in a day. All surplus relays are served by our backup infrastructure, ensuring no service interruptions. This is only a temporary measure, so the app owner should upgrade the plan to Pay As You Go or contact sales for an enterprise plan.
If your App doesn’t hit the 250,000 relay cap, the tiers are identical; the only difference is that you will be asked to enter your payment information during the creation of the App (or during the Upgrade process).
Info
If you created an App prior to September 27, 2022, it will show up as “Legacy” instead of “Always Free” or “Pay As You Go”. Your App will be grandfathered into a legacy free tier for a limited time, with no rate limiting put in place.
Calculate usage
On the page where you create your app, there is a pricing calculator that allows you to estimate what the costs could be, given a certain number of relays per day.
For example, 500,000 daily relays at a price per relay of $0.000007456 would cost approximately $56.68 per month.
Info
This is necessarily an estimate, as the way the relays vary over a period of time will affect the total cost. To take a simple example, if 1,000,000 relays were to happen in a single day, there would be a charge for 750,000 relays, but if those 1,000,000 relays were spread out equally over four days, there wouldn’t be a charge, due to the 250,000 free relays per day.
If your App uses less than 250,000 relays per day, across all of your Endpoints, you will not be charged.
Create an App
When you first create an account on the Pocket Portal, you will have no Apps, so the first thing to do is to create one.
Click the Apps link on the top bar to go to its section. This is where you manage your Apps.
To create a new App:
Click Create New Application.
Enter a name for your App (which can be anything, as it’s just a container).
Choose your tier: Pay As You Go or Always Free.
Info
See the section on Usage Tiers for the differences between the two tiers.
When finished, click Create App.
If you chose the Always Free tier, you will be taken to the App overview section.
If you chose the Pay As You Go tier, you will be redirected to a checkout page. Enter your payment information and click Subscribe. You will then be taken to the App overview section.
Congratulations! You have created an App and are ready to start connecting to Pocket’s network of decentralized infrastructure. You can find a list of your Apps by clicking the Apps link on the top bar.
App Overview
Clicking one of your Apps in the list takes you to the App Overview page.
The App Overview displays all the metrics associated with your App. The charts will start being populated as soon as you start submitting requests through an Endpoint associated with your App.
You’ll see key details:
Endpoints: List of Endpoints associated with the App, from the list of supported blockchains. Any number of Endpoints can be created for a given App.
Portal ID: Unique identifier for the App. This string is included as part of the URL for each Endpoint.
Secret Key: Security feature for Apps. If “Private Secret Key Required” is selected in the Security section, the Secret Key will need to be sent along with the request using HTTP Basic Authentication.
Public Key: Unique identifier for a given App that will allow you to inspect the App on-chain.
Manage Endpoints
Every App gets created with Ethereum Mainnet as its single Endpoint.
To add a new Endpoint to your App:
Click Add New in the Endpoint section.
In the box that appears, click the name of the chain you wish to connect to. You may also use the search box to narrow down the choices.
The new Endpoint will then appear in the list.
To delete an Endpoint, click the trash can icon next to the Endpoint.
The network prefix. You can find them on the list of supported blockchains in the column Portal API Prefix. For example, Ethereum Mainnet is eth-mainnet.
The main URL (gateway.pokt.network/v1/)
If it’s a load-balanced endpoint (and most of them are), it will also have the /lb/ prefix.
The Portal ID, which is unique to your App.
Requests
The Requests page for a given App shows the success and error rates for your App across all of your Endpoints. It will also log the errors found as part of the requests made.
Security
The Security page for a given App allows you to better secure your Endpoints and your associated dApps. We recommend setting some or all of these for your specific App to reduce the risk of undesired activity.
Private Secret Key Required: When this is enabled every request sent to an Endpoint has to be sent using HTTP Basic Authentication with your Secret Key to be accepted. (When using curl, you would add --user :YOUR-SECRET-KEY.)
Approved Chains: Limits the Endpoints to be used only with specific chains. This list need not be exactly the same as the list of Endpoints on the App Overview page.
Whitelist User-Agents: Limits requests to only the HTTP User-Agents specified. If a User-Agent not on the list attempts to connect to the Endpoint, the request will be blocked. If nothing is specified, all User-Agents will be accepted.
Whitelist Origins: Limits requests to only the HTTP Origins specified. If an Origin not on the list is used in a request to the Endpoint, the request will be blocked. If nothing is specified, all Origins will be accepted. Wildcards are supported.
Whitelist Contracts: Limits requests to the smart contract addresses specified. If the Endpoint is used in a contract address not specified in the list, the request will be denied. Each contract address listed is chain-specific. If nothing is specified, all contract addresses on all chains will be valid.
Whitelist Methods: Limits requests to use specific RPC methods. If a request uses a method not on this list, the request will be denied. Each method listed is chain-specific. If nothing is specified, all methods on all chains will be valid.
When making changes, be sure to click Save at the bottom of the page.
Notifications
Info
This section is only visible for Apps on the Always Free tier. If your App is on the Pay As You Go tier, you will see the Plan Details page instead.
On this page, you can set up email alerts to be warned when you are approaching your relay limits.
There are four thresholds available for alerts. Each can be individually toggled:
25% of 250,000 relays per day
50% of 250,000 relays per day
75% of 250,000 relays per day
100% of 250,000 relays per day
You can also see your weekly bandwidth usage on this page, including average, maximum, and minimum values.
When making any changes, be sure to click Save Changes.
Plan Details
Info
This section is only visible for Apps on the Pay As You Go tier. If your App is on the Always Free tier, you will see the Notifications page instead.
This page shows you details about your subscription, including your total relays on the billing period, and your latest invoice. You can view and download your latest invoice, as well as manage your plan.
Test your Endpoint
Once you’ve set up your Apps and Endpoints to your liking, you can send requests to them to test that your settings are correct.
For EVM-based chains such as Ethereum, you can refer to the official JSON-RPC specification. Below is an example of such a request using cURL.
Pocket also maintains API docs that include various methods to test out your specific Endpoint, by generating and sending requests to that Endpoint.
To test out your Endpoint, navigate to the API Docs page for the Pocket blockchain, and click any of the queries on the left sidebar. For example, a simple request is to check the block height.
Once on the page, enter your Portal ID in the box on the right and then click Send API Request. The response will be shown below.
There are also code samples for various platforms available in the Request Sample box. You can copy these code samples and use them in your own test applications.
More questions?
If you have more questions about the Portal, please see the Portal FAQ. And you can always reach out to the team on Discord.
Popular Libraries
.NET – Web3
Overview
Web3 is a simple wrapper for interacting with JSON RPC, and is provided by Nethereum, a suite of .NET Ethereum development tools.
using System;
using System.Threading.Tasks;
using Nethereum.Web3;
namespace NethereumSample
{
classProgram {
staticvoid Main(string[] args)
{
GetAccountBalance().Wait();
Console.ReadLine();
}
staticasync Task GetAccountBalance()
{
var URL = "https://<PREFIX>.gateway.pokt.network/v1/lb/<PORTAL-ID>";
var ACCCOUNT = "0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae";
var web3 = new Web3(URL);
var balance = await web3.Eth.GetBalance.SendRequestAsync(ACCOUNT);
Console.WriteLine($"Balance in Wei: {balance.Value}");
var etherAmount = Web3.Convert.FromWei(balance.Value);
Console.WriteLine($"Balance in Ether: {etherAmount}");
}
}
}
Go – ethclient
Overview
The ethclient package built to enable remote communication directly to an ethereum mode, including RPC access over HTTP.
Ethers is a JavaScript library for interacting with Ethereum and the ecosystem that's been built on it, including first class support for Pocket Network.
Web3.py is a Python library for interacting with Ethereum nodes; it originally began as a port of web3.js, but has evolved to better serve the needs of Python developers.
asyncfnmain() -> web3::Result<()> {
let url ="https://<PREFIX>.gateway.pokt.network/v1/lb/<PORTAL-ID>";
let transport = web3::transports::Http::new(url)?;
let web3 = web3::Web3::new(transport);
let account ="00a329c0648769a73afac7f9381e08fb43dbea72";
println!("Calling balance.");
let balance = web3.eth().balance(account, None).await?;
println!("Balance of {:?}: {}", account, balance);
Ok(())
}
Swift – web3.swift
Overview
web3.swift is a Swift API that supports a subset of the Ethereum JSON RPC, as well as additional methods to ease ENS, ERC20, and ERC721 interaction.
Apeworx allows you to specify multiple ecosystems, networks, and providers.
Apeworx specifically has configurations in ape-config.yaml for connecting to
live network nodes; it’s here where you would want to specify the Portal
Endpoint. While this section is called geth, it’s not limited to just geth
nodes.
For our example, let’s specify 2 ecosystems, Ethereum and Polygon, both
including testnets.
Hardhat allows you to configure networks through a networks object exported
in the hardhat.config.js file. Here’s an example of adding networks for
Ethereum and Polygon, both mainnet and testnet.
require("@nomicfoundation/hardhat-toolbox");
constPORTAL_ID="<PORTAL-ID>";
// Replace these privates key with your respective account private key
// To export your private key from Metamask, open Metamask and
// go to Account Details > Export Private Key
// Beware: NEVER put real Ether into testing accounts
constMAINNET_PRIVATE_KEY="YOUR MAINNET PRIVATE KEY";
constGOERLI_PRIVATE_KEY="YOUR GOERLI PRIVATE KEY";
constPOLY_PRIVATE_KEY="YOUR MAINNET PRIVATE KEY";
constMUMBAI_PRIVATE_KEY="YOUR MAINNET PRIVATE KEY";
module.exports= {
solidity:"0.8.9",
networks: {
mainnet: {
url:`https://eth-mainnet.gateway.pokt.network/v1/lb/${PORTAL_ID}`,
accounts: [MAINNET_PRIVATE_KEY]
},
goerli: {
url:`https://eth-goerli.gateway.pokt.network/v1/lb/${PORTAL_ID}`,
accounts: [GOERLI_PRIVATE_KEY]
},
polygon: {
url:`https://poly-mainnet.gateway.pokt.network/v1/lb/${PORTAL_ID}`,
accounts: [POLYGON_PRIVATE_KEY]
},
mumbai: {
url:`https://poly-mumbai.gateway.pokt.network/v1/lb/${PORTAL_ID}`,
accounts: [MUMBAI_PRIVATE_KEY]
}
}
};
Then, say you wanted to deploy to Goerli, you’d simply run your deployment
as follows:
npx hardhat run scripts/deploy.js --network goerli
Solidity & Vyper – Truffle
Overview
Truffle is a JavaScript based EVM development environment, testing framework, and asset pipeline.
Truffle allows you to configure networks through a networks object exported
in the truffler-.config.js file. Here’s an example of adding networks for
Ethereum and Polygon, both mainnet and testnet.
To create a POKT wallet with the official Pocket wallet web app You can use the official wallet web app to create your wallet.
Click “Create”.
Enter a unique passphrase.
Warning
The passphrase unlocks/decrypts an encrypted version of the private key that is stored in a Key File. Make sure to store your passphrase safely, if you lose it you will not be able to unlock your Key File.
Download the Key File by clicking the blue download icon and click Continue to open your account.
If you accidentally click Back, as long as you downloaded your Key File and saved your passphrase, you will now be able to import your new wallet.
Warning
Make sure to store your Key File safely, if you lose it you will only be able to use the Private Key method to import your wallet anywhere. The Key File is the more secure method of importing your wallet since it is encrypted by your passphrase.
Click “Reveal Private Key” then enter your passphrase again to reveal the Private Key for your wallet.
Warning
Store your Private Key safely. This will be a second method for you to import your wallet in the event that you lose your Key File or passphrase. However, this is also less secure than the Key File since the Key File is encrypted by your passphrase.
Warning
Never reveal your Private Key to anyone. If someone has access to your Private Key, they have full access to all the funds. The only application that should ever need access to your Private Key is a wallet.
Backup wallet
It is important that you back up your Key File, passphrase, and private key securely. There are two considerations when choosing a backup method:
Theft Prevention: make sure no-one else can access your Key File, passphrase, or private key
Loss Prevention: make sure you don’t lose access to your Key File, passphrase, or private key
The most secure way to prevent theft is to store your Key File, passphrase, and private key on a USB drive (or other secure external drive), disconnected from any online “cloud” service or internet-connected computer that can be hacked.
Info
POKT is planned to have Ledger support soon, which will provide more advanced functionality than a USB drive.
For extra-secure theft prevention, you should split the Key File, passphrase and private key across separate drives and password-protect these drives so that anyone who gets their hands on a drive can’t access the contents. For extra loss prevention, you should make multiple copies of these drives and store them in different locations, such as a personal safe, the safe of a trusted family member, and a bank safety deposit box.
Once you have created your backups, delete all traces of the Key File, passphrase and private key from the hard drive of the computer you used for account setup. To ensure deletion, consider using software such as sDelete (Windows) or shred followed by rm (Linux).
Info
For more convenience, you may consider using a password manager that can store encrypted files. Just be mindful that you risk theft if your master password is compromised and you risk loss if you forget your master password.
Import wallet
The official wallet web app has two methods of importing your wallet. The Key File is the more secure method of importing your wallet since it is encrypted by your passphrase.
Key File import
Click Select File then choose your keyfile.json from your local file explorer.
Enter your Key File passphrase, which you specified when creating the wallet.
Click Import.
Private key import
Enter your Private Key.
Create a temporary passphrase that will secure your session until you log out of the wallet. This is a measure to prevent anyone with access to your computer from stealing your funds.
Now supporting Unstoppable Domains in the POKT Wallet.
Users can now send transactions to an Unstoppable Domain from a POKT Wallet address. Create an Unstoppable Domain for your wallet here.
For guidance on how to send a transaction with a UD, check out this video:
POKT is available to purchase on multiple global exchanges. Follow this DAO proposal for updates on official listings.
Note that you can’t stake POKT from exchanges. To stake your POKT you would need to withdraw to your wallet (see below).
Over-the-Counter (OTC)
Over-the-Counter (OTC) trading desks are white-label markets operated by trusted intermediaries who match buyers and sellers. They are typically used for large volume trades.
The POKT community has a number of OTC desks which can be found here.
Transfer POKT to Your Wallet
To receive POKT, you must use your Address, not your Public Key. The Public Key is used for API transactions, not basic wallet actions.
Stake POKT
There is no many-to-one delegation in Pocket Network. You cannot simply stake POKT from your wallet and then forget about it. A POKT account must be staked on a node that is relaying RPC requests. However, if you do not have the skills to run a node yourself, you still have options.
Run Your Own Node
Running your own node is an option if you possess both of the following:
The DevOps skills to run your own node
More than 15,000 POKT to meet the minimum node stake
If you don’t possess the skills to run your own node, but you do have more than 15,000 POKT for the minimum node stake, you can pay someone else to run your node(s). Payment models include a monthly subscription and a revenue share of your node’s POKT earnings.
If you possess neither the skills nor more than the 15,000 POKT minimum node stake, you can join a staking pool. Like the third-party node runners above, staking pools are also entirely custodial, so be sure to do your due diligence. You can view the list of staking pools here.
Learn Pocket
Vision
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.
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.
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:
Load balancing at the protocol level incentivizes decentralization and minimizes the need for buffers
Staking and inflation enables more efficient resource allocation
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
Indexers
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.
Protocol
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.
Servicing
Overview
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
To register for decentralized infrastructure, an Application must stake the native cryptocurrency POKT in the network.
The amount of the sanctioned throughput (per request) is determined by the amount the Application stakes in the network.
To register to provide decentralized infrastructure, a Servicer must stake the native cryptocurrency POKT in the network.
After the subsequent staking, an Application is paired with Servicer(s), during which time the servicing interaction takes place.
For providing the decentralized infrastructure, Servicer receives an amount of the native cryptocurrency POKT proportional to the amount of throughput (in requests) served.
Once an Application or Servicer unstakes, they are unregistered from Pocket Network and the stake is returned to their account.
Sessions
Distribution
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.
Generation
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
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.
Throughput
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)
Relays
Payload
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
Metadata
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
ClientSignature: The Elliptic Curve Digital Signature of the client
Preserves the integrity of the Relay data
Needed at Proof/Claim verification level
Response
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:
Claim Transaction
Merkle Root of Relay Evidence
Number of Relays serviced
Evidence Type (Relay or Challenge)
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:
Generate the Merkle Tree using the SHA3-256 hash of the Relay Evidence as the leafs
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
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.
The Servicer submits a Proof Transaction containing the selected leaf (Relay Evidence) and the corresponding Merkle Proof (branch)
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)
All of the Validators confirm the validity of the Proof Transaction, completing the Zero Knowledge Range Proof
Tokens are minted to the address of the Servicer proportional to the amount of Relays served.
Security
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:
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
Economics
TL;DR
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.
Overview
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.
Info
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.
Info
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.
Transactions
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
Info
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.
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.
Info
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:
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:
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
Overview
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.
Warning
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)
Hardware
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.
Stake
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:
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.
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.
Warning
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.
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.)
Info
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:
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.
Info
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.
Info
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.
Info
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:
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 Number
Bin with Exponent
Reward multiplier
1
$1^1$
1x
2
$2^1$
2x
3
$3^1$
3x
4
$4^1$
4x
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:
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.
Current values of these parameters (and all others) can be found on the Protocol Parameters page.
Info
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).
Info
For more information and to read the actual DAO proposals on inflation management, please see the following:
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:
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.
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.
Pocket is quite a unique blockchain network, because there are two ways for nodes to earn POKT:
Servicing: processing requests to/from blockchains on behalf of apps
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:
100% - (ProposerPercentage+DAOAllocation) to all the nodes who were Servicers, proportional to the number of relays they did.
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.
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:
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.
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.
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.
Quality Incentives
v0 – Quantity-based
85% 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%.
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.
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.
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).
Nakamoto
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.
BFT
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.
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:
Efficiency and Scalability – making sure that more peers can connect without a major impact to the network performance
Fault and Partition Tolerance – despite any number of breakdowns that happen between nodes, the network can continue to operate
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.
Servicers need to be able to inform the network of transactions made
Validators need to be able to communicate with each other during consensus and with the whole network when a new block is created
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:
Communicate blocks and transactions across the network
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:
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
Determine its own and max depth of the tree
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.
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.
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.
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:
Versioning of the state dataset
Byte-perfect consistency of the data encoding
Schema definition mechanism
Deterministic write mechanism
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
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.
This page contains a listing of all the on-chain parameters for Pocket Network and their current values, as well as some relevant off-chain parameters.
These parameters are sorted by module. You can find a description of each parameter by clicking on the parameter name.
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.
AppUnstakingTime
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.
BaseRelaysPerPOKT
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.
MaxApplications
Current Value:
2295
The number of staked applications that the protocol allows.
MaximumChains
Current Value:
15
An app can only be configured for up to this many chains on one stake.
ParticipationRateOn
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.
StabilityAdjustment
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.
The number of blocks allowed before a Session tumbles.
DAOAllocation
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.
DowntimeJailDuration
Current Value:
3600000000000
The amount of time (in nanoseconds) before a node can unjail and resume service.
MaxEvidenceAge
Current Value:
120000000000
The amount of time (in nanoseconds) a node has to submit their Tendermint evidence in memory before it expires.
MaximumChains
Current Value:
15
A node can only be configured for up to this many chains on one stake.
MaxJailedBlocks
Current Value:
37960
The amount of time (in blocks) a node has to unjail before being force unstaked and slashed.
Warning
Warning: Reaching MaxJailedBlocks will result in a node’s entire stake being slashed.
MaxValidators
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.
MinSignedPerWindow
Current Value:
0.600000000000000000
The minimum proportion of the SignedBlocksWindow that a node must sign to stay out of jail.
Info
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.
ProposerPercentage
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.
RelaysToTokensMultiplier
Current Value:
485
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.
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.
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.
ServicerStakeWeightCeiling
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).
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.
SignedBlocksWindow
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.
Info
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.
SlashFractionDoubleSign
Current Value:
0.000001000000000000
The % of a node’s stake that is burned for double signing, where 1 is 100%.
SlashFractionDowntime
Current Value:
0.000001000000000000
The % of a node’s stake that is burned for downtime, where 1 is 100%.
StakeDenom
Current Value:
upokt
POKT amounts are defined by the protocol. Read more about POKT denominations.
StakeMinimum
Current Value:
15000000000
The minimum stake required of a node, denominated in StakeDenom, for the economic security of the protocol.
UnstakingTime
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.
ClaimExpiration
Current Value:
24
The amount of time (in blocks) a node has to submit a proof for an already existing claim.
ClaimSubmissionWindow
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.
MinimumNumberOfProofs
Current Value:
10
The minimum number of relays a node must have for a claim and proof to be payable.
ReplayAttackBurnMultiplier
Current Value:
3
The multiplier slash factor for submitting a replay attack. The base slash is directly proportional to the amount of relays claimed.
SessionNodeCount
Current Value:
24
The number of nodes an app will be matched with in a session.
These parameters control how transactions are constructed.
FeeMultipliers
Current Value: 1
The multiplier factor for each transaction type. The base transaction fee is universally set at 10,000 uPOKT.
MaxMemoCharacters
Current Value:
75
The character limit of transaction memos.
TxSigLimit
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.
ACL
Access control list for updating the on-chain parameters. Currently all parameters are owned and managed by the DAOOwner address.
DAOOwner
Current Value:
a83172b67b5ffbfcb8acb95acc0fd0466a9d4bc4
The account which has the permission to submit governance transactions on behalf of the DAO.
Upgrade
Current Value:
Height: 74616
Version: 0.9.1.1
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.
ReturnOnInvestmentTarget
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.
USDRelayTargetRange
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.
Glossary
Application
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.
Endpoint
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).
Jail
Situation where a Pocket node is denied the ability to serve relays.
A node can be jailed for one of two reasons:
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.
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.
PEP
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).
PIP
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).
POKT
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.”
Portal
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.
PUP
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)
Relay
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.
RelaysToTokensMultiplier
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.
Servicer
Any node which is eligible to serve RPC requests for Applications. By default, a node is a Servicer.
ServiceURI
The endpoint that Servicers expose to provide Applications the functionality they need to send relays via the Pocket Network RPC to said Servicer.
Session
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.
Stickiness
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.
Trophy
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.
v0
Current active iteration of the Pocket protocol. Often used in contrast to the upcoming v1 update.
v1
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.
Validator
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.
WAGMI
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.
wPOKT
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.
Use Pocket
Public RPC Endpoints
How to Customize Your Endpoint (e.g. MetaMask)
To change your endpoint in MetaMask, do the following, filling in the fields from the table below:
Click on the Networks drop-down menu, then press Add Network
Under the Network Name field, write <Network Name> Pocket Portal
Within the New RPC URL field, copy and paste<RPC URL>
(Optional) Put <ChainID> in the ChainID field
(Optional) Write <Symbol> as the Symbol
(Optional) Add <Explorer URL> as the Block Explorer URL
Don’t forget to save
Info
If you receive this error message from MetaMask Invalid number. Enter a decimal or '0x'-prefixed hexadecimal number then leave the optional fields blank.
We have created a public Avalanche RPC endpoint with up to 1M requests per day to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
To get started connecting to Pocket’s infrastructure for Avalanche C-Chain, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write Avalanche Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URL https://avax-mainnet.gateway.pokt.network/v1/lb/605238bf6b986eea7cf36d5e/ext/bc/C/rpc
Put the hexadecimal 0xa86a or decimal 43114 in the ChainID field
Write AVAX as the Symbol
Add https://cchain.explorer.avax.network/ as the Block Explorer URL
Don’t forget to save
BNB Smart Chain (BSC)
We have created a public BSC RPC endpoint with up to 1M requests per day to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
To get started connecting to Pocket’s infrastructure for BSC, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write BSC Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URLhttps://bsc-mainnet.gateway.pokt.network/v1/lb/6136201a7bad1500343e248d
Put the decimal 56 in the ChainID field
Write BNB as the Symbol
Add https://bscscan.com as the Block Explorer URL
Don’t forget to save
Connecting MetaMask to DFK Chain
For those who play Defi Kingdoms, you can use Pocket’s public RPC endpoint for DFK Chain and take advantage of Pocket’s decentralized infrastructure.
There are two ways to connect your MetaMask wallet to DFK Chain. Choose whichever method you prefer.
Click the down arrow under DFK Chain to expand the entry.
In the row with the URL that begins with htps://avax-dfk.gateway.pokt.network... click Connect Wallet. (You may need to scroll the window to the right to see this.)
Click Add to MetaMask.
When prompted, click Approve in the MetaMask interface.
Add manually
In MetaMask, click the Networks drop-down menu, then select Custom RPC.
Under the Network Name field, type DFK Chain POKT.
Within the New RPC URL field, copy and paste this endpoint URL:
For the Block Explorer URL, add https://subnets.avax.network/defi-kingdoms/dfk-chain/explorer.
Save changes.
Ethereum (ETH)
We have created a public Ethereum RPC endpoint with up to 10M requests per day to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
To get started connecting to Pocket’s infrastructure for Ethereum mainnet, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write Ethereum Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URL https://eth-rpc.gateway.pokt.network
Put the decimal 1 in the ChainID field
Write ETH as the Symbol
Add https://etherscan.io as the Block Explorer URL
Don’t forget to save
Evmos
We have minted a public Evmos RPC endpoint to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infrastructure.
To get started connecting to Pocket’s infrastructure for Evmos, do the following:
Click on the Networks drop-down menu, then press Custom RPC.
Under the Network Name field, write Evmos Pocket Portal.
Within the New RPC URL field, copy and paste this endpoint URL https://evmos-rpc.gateway.pokt.network.
Put the decimal 9001 in the ChainID field.
Write EVMOS as the Symbol.
Add https://evm.evmos.org/ as the Block Explorer URL.
Don’t forget to save.
Fuse
We have created a public Fuse RPC endpoint with up to 3M requests per day to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
To get started connecting to Pocket’s infrastructure for Fuse, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write Fuse Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URL https://fuse-rpc.gateway.pokt.network/
Put the hexadecimal 0x7a in the ChainID field
Write FUSE as the Symbol
Add https://explorer.fuse.io as the Block Explorer URL
Don’t forget to save
Gnosis Chain (xDAI)
We have minted a public Gnosis RPC endpoint to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
To get started connecting to Pocket’s infrastructure for xDAI, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write Gnosis Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URL https://gnosischain-rpc.gateway.pokt.network/
Put the hexadecimal 0x64 in the ChainID field
Write XDAI as the Symbol
Add https://blockscout.com/poa/xdai as the Block Explorer URL
Don’t forget to save
Harmony
We have created a public Harmony RPC endpoint for applications and end-users to utilize!
To get started connecting to Pocket’s infrastructure for Harmony Mainnet Shard 0, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write Harmony Mainnet 0 POKT Portal
Within the New RPC URL field, copy and paste this endpoint URL https://harmony-0-rpc.gateway.pokt.network
Put the decimal 1666600000 in the ChainID field
Write ONE as the Symbol
Add https://explorer.harmony.one as the Block Explorer URL
Don’t forget to save
Use the provided RPC URL of Shard 0 if you want to send/receive transactions from exchanges or do any staking transaction type.
We have minted a public IoTeX RPC endpoint with up to 1M requests per day to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
To get started connecting to Pocket’s infrastructure for IoTeX, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write IoTeX Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URL https://iotex-mainnet.gateway.pokt.network/v1/lb/6176f902e19001003499f492
Put the decimal 4689 in the ChainID field
Write IOTX as the Symbol
Add https://iotexscan.io as the Block Explorer URL
Don’t forget to save
Polygon
We have created a public Polygon RPC endpoint with up to 5M requests per day to give people who use Metamask the opportunity to connect to Pocket’s decentralized, censorship-resistant infra.
We have minted a public Görli RPC endpoint with up to 10M requests per day to give players who are exploring the Conquest metaverse the opportunity to connect to Pocket’s decentralized, resilient infra!
To get started connecting to Pocket’s infrastructure for Görli testnet, do the following:
Click on the Networks drop-down menu, then press Custom RPC
Under the Network Name field, write Görli Pocket Portal
Within the New RPC URL field, copy and paste this endpoint URL https://eth-goerli.gateway.pokt.network/v1/lb/619f72f64df71a00392de6d9
Put the decimal 5 in the ChainID field
Don’t forget to save
For instructions on how to get started with Conquest, check out their documentation and video.
MyCrypto is an open-source, client-side tool for generating Ethereum wallets, handling ERC-20 tokens, and interacting with the blockchain more easily. Developed by and for the community since 2015, they’re focused on building awesome products that put the power in people’s hands.
This is why we want to give users an opportunity to connect to our own infrastructure!
Open the MyCrypto desktop application, if you don’t have it yet, then download it here: https://download.mycrypto.com
Find “Change Network” on the bottom left-hand side of the menu, then click on it.
Under “Show Other Networks”, click “+Add Custom Node” to bring up the “Set Up Your Custom Node” menu.
In the “Node Name” field, write Pocket Network Gateway
Keep the Network set to ETH (Ethereum)
Then, copy and paste in the Endpoint URL: https://eth-mainnet.gateway.pokt.network/v1/5f46739e2164c49f99af2480
Do not check the HTTP Basic Authentication box
Then, press the “Save & Use Custom Node” button
Use Decentralized Infra
Rotki
Rotki is an open-source portfolio tracker and accounting/analytics tool that protects your privacy.
We’ve sponsored a public Ethereum RPC endpoint for Rotki users in order to add an extra layer of privacy when using the application.
To get started connecting to Pocket’s censorship-resistant infrastructure for Ethereum, do the following:
Open and login into your local application.
2. Toggle to account, then open settings.
3. Scroll down to the Local Nodes section, then delete the default RPC endpoint.
4. Copy & Paste this URL into the Ethereum Node RPC Endpoint field:
In this section, you’ll get information on running a Pocket node.
These details are mostly for “intermediate” node runners, who are familiar with running full nodes and have the knowledge required to avoid getting lost. If you would like a more beginner’s tutorial, visit Zero To Node. You may also want to explore node-hosting services.
Want to understand the economics of running a Pocket node before you dive in? Read about Node Economics.
These are just the hardware requirements for your Pocket node. You’ll also most likely be running the full nodes of other blockchains, which will have their own hardware requirements.
Software
There are three ways to install the software you need to run Pocket Network:
Reverse Proxy: For SSL termination and request management
Ports: Expose Pocket RPC (Default: 8081) and P2P port (Default: 26656)
SSL Cert: Required for validator’s serviceURI
Set open files limit
ulimit -Sn 16384
Info
The value of ulimit -Sn should be set to greater than or equal to the sum of the following:
Maximum inbound peers
Maximum outbound peers
Maximum open connections
gRPC maximum open connections
Desired concurrent Pocket RPC connections
100 × Constant number of Write-ahead Logging, database, and other open files
Warning
This limit is set based on the standard configuration provided with Pocket Core in <POCKET_DATADIR>/config/config.json. If you modify your config, you will need to ensure that you modify your open files limit as well.
Secure your server
Make sure the server that hosts your node is protected by up-to-date anti-virus and anti-malware software, as well as a firewall.
Your node’s private key will be available in plaintext on the server, so your key is only as secure as your server.
Pocket Node Setup
Once you have your environment set up, you are now ready to deploy your node.
Create an account
An account is needed to participate at any level of the network.
pocket accounts create
> Enter Passphrase
> Account generated successfully:
> Address: <address>
Info
Alternatively, you can create your account using the Wallet app, then use the encrypted import command to import the account into your node environment:
Backup your private key to an encrypted and ASCII armored JSON file, to the specified --path , using the export option. You will be prompted for the decrypt passphrase and an encryption passphrase for the exported account. You will also have the option to add a hint to help remember your passphrase.
Do not use your node’s account as your personal account address. Since the node’s private key is stored in plaintext on the server, the key is as secure as your server is. Regularly sweep your node’s rewards and transfer them to a more secure account stored offline.
To stake a node in Pocket Network, the account must have a balance above the minimum stake, which is 15,000 POKT (or 15,000,000,000 uPOKT).
Warning
We recommend staking more than the absolute minimum node stake of 15,000 POKT (such as 15,100) as a reasonable buffer against operational slashes which can occur on even properly configured nodes as well as misconfigured and misbehaving ones. If slashes cause your node stake to drop below 15,000, you node will be forcibly unstaked.
You won’t be able to send POKT using the command line until you have your node set up. Until then, you can use the Wallet app.
If you’re using the testnet, you can fund your account using the Testnet Faucet.
Set the account operator
pocket accounts set-validator <address>
Info
Check that the command was successful with pocket accounts get-validator
Set Relay Chains
A Relay Chain is a blockchain that a Pocket node connects to or runs in order to service applications. Applications access Relay Chains through the serviceURI, the endpoint where nodes publicly expose the Pocket API. You can view a list of all the Relay Chains that Pocket supports.
Once you have your Relay Chains properly configured, you can set up your node to serve requests to those Relay Chains via the generate-chains command. Relay Chains are referenced through a four digit ID (example: 0021 for Ethereum Mainnet).
A wizard will step you through the process of adding each Relay Chain ID, and will output a $HOME/.pocket/config/chains.json file when done.
If you were only servicing Pocket nodes, the response would look like this:
> Enter the chain of the network identifier:
<Relay Chain ID> (Example: 0001)
> Enter the URL of the network identifier:
<Secure URL to Relay Chain>
Would you like to enter another network identifier? (y/n)
n
Test that your node is configured correctly by simulating a relay.
pocket start --simulateRelay
Then send a curl request to your validator URL http://<your node>:<your pocket rpc port>/v1/client/sim to test if your node responds.
curl -X POST --data '{"relay_network_id":"<relay chain ID from chains.json>","payload":{"data":"{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBalance\",\"params\":[\"0xe7a24E61b2ec77d3663ec785d1110688d2A32ecc\", \"latest\"],\"id\":1}","method":"POST","path":"","headers":{}}}' <your node URL>:8081/v1/client/sim
If successful, you’ll see a 200 OK response. If you see a 400 Bad Request, you either have incorrect/missing parameters in the request or bad formatting in the data field.
Finally, stop your node with Ctrl-C. If you don’t, you’ll be leaving –simulateRelay running, which means anyone will have unfiltered access to your node.
Download snapshot
Downloading from the latest snapshot will drastically shorten the time it takes to sync the blockchain. The easiest way is by downloading with wget and extracting the archive as it downloads.
Ensure the node is all the way synced before proceeding to the next step.
Stake the node
Stake the account to participate in the network. Staking as a servicer node locks up POKT tokens that can be burned as a security mechanism for bad acting.
You should at least 1 POKT unstaked to pay the transaction fees for your node’s claim and proof transactions.
All node runners must always maintain a liquid (unstaked) balance of at least 0.02 POKT in order to submit the claim and proof transactions (which each have a transaction fee of 0.01 POKT) that generate their rewards. If a node successfully submits both the claim and proof, they will earn enough POKT to submit the next claims and proofs, and so on. However, if a node falls below a liquid balance of 0.02 POKT, their revenue will be halted.
Claim transactions have 3 sessions, the ClaimSubmissionWindow, to be successfully submitted after the conclusion of the session in which the work was done, otherwise they are lost. If a claim transaction fails, Pocket Core will auto-repeat the transaction once in each new session, until the claim is lost. This means your node will automatically take 3 attempts to submit the claim. There is a claim submission window because the global secret key that determines the required proof leaf is revealed once that window closes. Extending the claim submission window would delay the time at which the corresponding proof can be sent and rewards earned.
If you manage to successfully submit the claim transaction, you then have 120 blocks, the ClaimExpiration period, to submit the corresponding proof transaction, otherwise the pending claim expires. There is a claim expiration date because otherwise the claims would remain in the state and bloat the blockchain.
Warning
Bad Behavior Warning: Pre-staking
Pre-staking is the act of a node runner staking on a RelayChainID prior to spinning up the RelayChain node. This behavior has an extremely negative impact on the quality of service for new chains due to apps being matched in sessions with Pocket nodes that don’t actually have RelayChain nodes connected to them. If you do this, your node will be challenged and slashed. You should always deploy your RelayChain node and simulate relays before staking your Pocket node for the RelayChainID.
Info
Staking a node successfully will earn you a trophy which can help you ultimately earn a vote in the DAO. Learn more about how to claim your vote.
Custodial and Non-Custodial Staking
Pocket has the ability for node runners to set up their nodes to run with “non-custodial” staking. This means that the Pocket address that is associated with staking and running the node is not the recipient of the funds once the node is unstaked.
This feature was activated as of version 0.9.1.3.
Node runners who staked their nodes prior to activation of non-custodial staking will have one opportunity to decide if they want their nodes to have custodial or non-custodial staking. After this point, if they wish to switch between the two options, they will need to unstake/restake their node.
Custodial staking
Custodial staking is the process of having the operator of the node be the recipient of the rewards of that node. This is true regardless of whether the node is a servicer or a validator.
In this scenario, only one Pocket account is needed to run a node. This account handles all aspects of node maintenance such as staking, editing the stake, unjailing, and unstaking.
Prior to activation of non-custodial staking, this was the only option that node runners had.
Non-custodial staking
Non-custodial staking allows for the separation of the node operator and reward recipient accounts. There are two Pocket accounts involved in the process: the operator account and the output account.
The operator account is responsible for signing claims and proofs, as well as block proposals and attestations. It needs to have some unstaked POKT to pay for these transactions.
The output account receives all rewards generated by the node. It also receives the original stake once the node is unstaked.
Non-custodial staking can be initiated by any operator or output account with sufficient POKT balance. The staked POKT will be taken from the account that initiates staking, and sent to the output account when unstaked.
Both the operator and output accounts can perform the staking and also any and all node maintenance (unstake, unjail, update relay chains, etc.).
Warning
The output account can’t be changed after staking, so it is vitally important to both make sure your output account is set correctly in the staking command, as well as to ensure access (keys) to that output account.
Failure to do both of these tasks will result in all rewards and staked funds being sent to an inaccessible account and lost forever! It is not possible for the operator account to receive staked POKT or rewards in a non-custodial configuration.
Benefits of non-custodial staking
An operator address must reside in a “hot” wallet on the node. This could potentially represent a security risk when the server is operated by a third-party. As third-party node hosting is common, there has arisen a need to have the recipient wallet for rewards not be on the same server as the node.
Non-custodial staking allows for this scenario. All you need to specify is the wallet (“output”) address, which is denoted when staking the node. The wallet can reside off the server.
Another benefit to non-custodial staking is the ability to pool rewards into a single account. Since each node has to have a distinct operator account, this would previously have resulted in rewards being split across multiple wallets, which is inconvenient for a node runner with many nodes.
Commands
The command for staking a node was updated when non-custodial staking was activated. Please see below for the updated command syntax.
The parameter custodial or non-custodial sets this permanently on your node. You can’t change this later unless you unstake.
The parameter <isBefore8.0> is boolean. It was set to be a transitional variable to denote whether or not the non-custodial activation has occurred. As this feature is now active, you will need to set this to false.
Be aware that the non-custodial command takes the operator public key as the argument (<operatorPublicKey>), not the operator wallet address like in the custodial command. The reason why the public key is used and not the address is for the situation where the owner of the output address is doing the staking, but does not also have ownership of the operator account. In this case, they may only have the public key for that account.
The non-custodial command adds <outputAddress> as the recipient of the staking rewards.
For more information on the full usage of these commands, including all parameters, please see the Pocket Core docs.
Important for existing nodes
If you have a node that was staked prior to the activation of non-custodial staking, you have only one opportunity to switch to non-custodial staking.
Any Pocket node command successfully issued (for example, to adjust the stake) will “lock” the node into custodial, unless a non-custodial command is issued with a valid output address. Following this, the only way to switch between custodial and non-custodial is to unstake/restake the node (and recall that there is a 21 day unstake period).
Important for all nodes
Be very careful entering the output address. You cannot change the output address after it is set. If you accidentally mistype the output address, your funds and your stake will be sent to that address and will be lost forever.
If you wish to change your output address, you can first unstake the node, and the rewards will be sent to that address. Then you can restake the node with a new output address.
Info
Make sure the operator account has some POKT left after staking, as it will still be responsible for ongoing claim and proof transactions, which each carry a 0.01 POKT transaction fee.
Unstaking
The unstaking process is the same using custodial or non-custodial staking.
During the unstaking process, a transaction is not generated when sending the staked POKT to the output address. This is intended behavior, and is similar to how proofs work on the blockchain.
Info
This lack of transaction happens regardless of whether you are using custodial or non-custodial staking, but in the case of custodial staking, there is no ambiguity on where the staked POKT is being sent.
In order to verify that your POKT is where it should be, we recommend querying the blockchain directly, instead of relying on a block explorer service that may not interpret the results accurately.
You can use the interactive API Docs to query the balance for an address at a given block height. Try it here.
Trustless Third Party Staking utilizes the protocol’s non-custodial staking feature to stake POKT without handing over custody of tokens to the Node Operator at any stage. With this method, Node Operators have no ability to steal either the stake or the rewards. Clients can also unstake without any intervention of the node operator and get their funds back.
Before proceeding, consult with your preferred Node Operator to verify if they support this method of staking.
This document demonstrates how to stake a node with 15k tokens and later upstake it to 60k.
Initially staking with 15k minimizes potential losses resulting from mistakes (e.g., typing incorrect output addresses or public keys).
The Non-Custodial Staking method requires the following addresses/wallets
Output Address
This is a wallet address that holds your funds and where staking rewards will be sent.
It is also known as the non-custodial address because you retain full control over it.
It is crucial never to share the private key associated with your output address and to make ample backups to ensure its security.
Output wallet can be created and accessed here: https://wallet.pokt.network
Operator Address
Created by the Node Operator, this address is used to manage and run your node. The Node Operator, using the key of the operator address, shares the responsibility
for editing the Domain and Chains with the Output Address. However, the Operator Address cannot control the funds; only the Output Address has this capability
The very first stake initiated from the output address establishes a link between the operator address and the output address.The Node Operator can then start running your node using the operator address. Any node rewards will be sent to the output address. Additionally, if unstaked, the unstaked funds will also go to the output address. An output address can be linked to multiple operator addresses
Introduction
Staking Bins:
You can stake 15k, 30k, 45k, or 60k+ tokens per node.
Stake-Weighted Servicer Rewards is a mechanism that offers higher rewards to node runners who stake more POKT on their nodes, with rewards determined by organizing nodes into bins based on their stake amount. The higher the stake, the greater the reward multiplier.
A 30k pocket node will earn the same as two 15k nodes for instance. It is a good practice to stake 10 tokens on top of that.
Notice there is a balance of 36.57 present. The node requires some POKT to pay for claiming rewards and also any staking operations(edit domain/chain) the node operator will perform. Either the output address owner or the node operator can keep the operator account topped up periodically.
IMPORTANT: Any balance in the operator address is accessible by the node operator. Do not send any amount other than what is intended to be used for fees, or better yet, let your node operators manage reward transaction fees.
Output Address Checklist
I know my output address and I want my staked funds (when unstaked) and rewards to be sent here. I have backed it up safely and I will not share the private keys/keyfile of this address ever.
Information to get from your Node Operator:
Node Operator Checklist
Operator Address
Operator Public Key
Chains your Nodes Operator will support
Domain
Preparing the Output Address
Login to your output address using the pocket official wallet below. Note down the password used to create the wallet. https://wallet.pokt.network/
IMPORTANT: Backup the keyfile.json using “export keyfile” and the password. Lose this and you will lose your funds. Then send 15011 tokens to this address. 15010 will be staked, leaving one for transaction fees.(Each transaction costs 0.01 POKT at the time this doc is written)
Fill in the operator public key, output address, chains, and domain from the above checklists.
Warning
1. Wrong output address will result in permanent loss of funds
2. Wrong operator public key may lock your funds for 21 days(you have to unstake to get your funds back)
Hit the Stake Node Button and verify your stake on POKTScan in 15-20 minutes.
Checklist
I verified that the node is staked non-custodial on POKTScan at the url https://poktscan.com/node/<myoperatoraddress> and it is showing the correct output address.
Managing Non-Custodial Nodes (Upstake)
Ensure you have correctly staked your node.
Login to your output address wallet, which must have a minimum balance of 45,001 POKT.
Complete the same staking form, but enter 60,010 instead of 15,010 to upstake (60010-15010 = 45000 is the amount to “upstake”)
Managing Non-Custodial Nodes (Unstake)
Login to your output address wallet
Go to manage non custodial Nodes
Enter Operator Address
Hit Unstake
FAQs
If the node operator unstakes from the operator keys where will the staked funds go?
Unstaking by either account sends staked funds to the output address at the end of the 21 day unbonding period.
Can the output address be changed once staked?
The output address cannot be changed once staked; ensure it’s correct and backed up.
How to verify that the output address is receiving the rewards?
Verify the output address is receiving rewards by checking its balance increase on POKTScan.
Can the operator change the chains or service url?
The operator can change chains or the service URL; consult your node operator or POKTScan for the latest information before upstaking.
Can I reuse the output address for another operator address?
You can reuse the output address for another operator address; rewards and unstaked funds from both operators will be sent to the output address.
If all rewards end up in the output account, how does the node operator get their reward share?
Node operators can’t access your rewards; you must send their share manually.
LeanPocket
LeanPocket (sometimes stylized as “LeanPOKT”) is a configuration that enables multiple Pocket instances to run on a single process, allowing node runners to consolidate resources, resulting in better scalability and reduced hardware costs.
LeanPocket is a feature available from version 0.9.2 and above.
Background
Pocket Core is a multi-threaded application, however, historically it has only allowed for one node per process. This means that if you wanted to run multiple Pocket nodes on the same server, each node, running its own isolated process, would each use their own resources: RAM, disk space, network throughput, etc. As many aspects of nodes use shared resources (copies of the blockchain, most notably) this was deemed very inefficient.
For example, at the time of writing, a Pocket node requires a minimum of 500GB of disk space and 16GB of RAM, and that’s not including the requirements of the other chains the node may be servicing.
LeanPocket is an optimization to the core client to allow nodes to share resources, significantly reducing resource requirements. This is a non-consensus-breaking change to the client.
The following charts show the benefits of implementing LeanPocket in your node fleet, though individual results will vary.
Info
LeanPocket is specifically geared toward multiple nodes running on the same server. If you are running a single node, or wish to keep each of your nodes running on different servers, LeanPocket will not have any benefit or effect.
Setup
To enable LeanPocket:
Create a new lean_nodes_keys.json file inside your Pocket configuration directory (typically .pocket).
Format the file with a JSON array of your node’s private keys:
Note the plural form in the command. The option set-validators is distinct from set-validator and is only relevant for LeanPocket.
Edit your node’s config.json file to add lean_pocket: "true"; in the pocket_config block.
Info
In some cases, the lean_pocket option may already be added to your config.json file, so make sure to search for it before potentially adding a duplicate value. If you find lean_pocket: "false"; change it to "true".
If you run a script that starts the Pocket service, add --keybase=false to the pocket start command.
Edit your proxy settings such that the /v1 endpoint is publicly accessible for every one of your nodes.
Warning
Failure to do this will prevent your nodes from broadcasting the correct version, which will interfere with consensus-related upgrades. When properly configured, all of your nodes should output the current version of Pocket Core on the /v1 endpoint.
Restart your Pocket service, making sure to add the --keybase=false option.
Tips
Using --forceSetValidators as an argument when starting Pocket will ensure that your validators are updated every time the process starts. If using this argument, you won’t have to use the set-validators command when you update your lean_node_keys.json file.
Do not use --useCache as an argument when starting Pocket, as it can delay restarting your node.
You can get a list of node with the get-validators command:
pocket accounts get-validators
You can add metadata to your lean_node_keys.json file for organizational purposes:
When the Pocket Core process first starts, if LeanPocket is activated, it will try to initialize an evidence and session cache for each node.
Therefore, you will see output like this in the logs:
Initializing {node address 1} session and evidence cache
Initializing {node address 2} session and evidence cache
Initializing {node address 3} session and evidence cache
Initializing {node address 4} session and evidence cache
Considerations and Risks
Because your nodes are commingling resources with LeanPocket, there is a risk of downtime on all of your nodes simultaneously. Depending on your risk for downtime, we recommend that you institute some form of failover system for your nodes, or perhaps divide your nodes into multiple LeanPocket-managed groups.
Since all LeanPocket nodes use the same configuration, it is not possible to serve different groups of chains on each individual node. Each node uses the same chains.json file.
If you are converting your node fleet into using fewer servers (or just one), you will want to ensure that your server open file limit (ulimit and fd on Linux-based systems) is sufficient, as these values still scale linearly with each additional node.
We don’t recommend running Validator nodes via LeanPocket at this time, because of the increased importance of the consensus state on the network.
Be aware that without LeanPocket, there is a one-to-one correlation between a node and its Peering ID, so when you use set validator, it will set the Peering ID to be the validator. However, with LeanPocket, the first node in the list is your Peering ID for every node managed by LeanPocket.
It is very important, both for network security and for performance of your own node, to keep your Pocket node up-to-date with the latest version of the Pocket software. The following steps will show you how to update your Pocket node.
Release-specific changes
Each release may have specific modifications you need to make. This is just a general guideline for the steps you’ll typically take to update your node. Check the release notes for release-specific details.
Shutdown Pocket Core
Stop your Pocket Core instance running by submitting the shutdown command.
pocket stop
Warning
Once you shutdown Pocket Core, you will have 4 blocks (60 minutes) to complete the update and start Pocket Core again before your node gets jailed for downtime.
Backup blockchain data
Backing up your blockchain data will ensure a faster resync when you restart your node.
Navigate inside your $HOME/.pocket/ dir and save data/ (the entire directory):
cp -r ~/.pocket/data ~/backup/data
In the event of a corrupted database you can delete the bad data rm -r ~/.pocket/data and replace it with your backup cp -r ~/backup/data ~/.pocket/data.
Info
If you don’t have a backup, a temporary backup datadir may be provided alongside a release.
Ensure the latest Go version
Check your golang version. The release notes will specify which version it should be.
go build -o $GOPATH/bin/pocket ./app/cmd/pocket_core/main.go
Homebrew
Pull the latest tap:
brew upgrade pokt-network/pocket-core/pocket
Docker
Pull the latest container image:
docker pull poktnetwork/pocket-core:RC-0.9.2
docker pull poktnetwork/pocket:RC-0.9.2
Update config.json
Run the update-configs command, which creates a new config file ($HOME/.pocket/config/config.json) and backs up the old config file ($HOME/.pocket/config/config.json.bk).
pocket util update-configs
You’ll need to manually compare your backup file with the new file to copy over your personal config details.
Warning: Use at your own risk. These links are not directly associated with Pocket Network and do not constitute an endorsement, guarantee, warranty, or recommendation by Pocket Network, Inc., Pocket Network Foundation, or the Pocket DAO. Do conduct your own due diligence before deciding to use any third party services.
Node-Hosting Services
If you are interested in staking your POKT in a node but don’t have the time or technical know-how, below you will find a link to the available options to have your node operated by a third-party.
Warning: Use at your own risk. The appearance of third party descriptions and hyperlinks on the above linked sites does not constitute an endorsement, guarantee, warranty, or recommendation by Pocket Network, Inc., Pocket Network Foundation, or the Pocket DAO. Do conduct your own due diligence before deciding to use any third party services.
Seeds
Seed nodes enable newly configured Pocket nodes to find peers on the network and store them in their local address book.
You can use the --seeds flag when starting the Pocket process to set the seeds for your Pocket node. Alternatively, you can set the seeds in your config.json file under the "P2P" block.
Does my blockchain node need to be synced before I start my Pocket node?
Yes. Every node on the Pocket Network needs to have the most up to date information of the blockchain they are supporting. If you start joining sessions before your node has caught up to the current block height, you will be returning incorrect data, and if incorrect data is being returned, your node will be slashed.
How many blockchains can one node support?
Your node can support up to the number of chains defined by the MaximumChains parameter. This limit is not definitive and can be changed by the DAO.
Can I add a load balancer address in my chains.json if I have multiple blockchains under one domain?
Yes you can! Just make sure you have the necessary ports open to be able to successfully send relays to the proper network.
How can I add more blockchains to my node?
Add the new RelayChainIDs to your chains.json file, then run the stake command
again for your node. Since you’re already staked, running the command “updates”
your staking configuration.
No, for the duration of the unstaking process as determined by the UnstakingTime parameter, your node will not be eligible for sessions.
Do each of my nodes need a unique IP address?
You need a dedicated domain for each node, but the nodes can be on the same machine, behind the same IP address. It would take properly configuring your Reverse Proxy and Firewall/Router, but it can be done.
How do I set my ulimit?
As a best practice, do not use root to run the pocket process. When you set the ulimit for your instance, it’s important to set it in the user profile that is running the pocket-core instance.
Warning
Make sure that you’re setting the ulimit for the specific account that’s running the pocket process.
To calculate the ulimit, you will have to define a few parameters as shown below:
({ulimit -Sn} >= {MaxNumInboundPeers} + {MaxNumOutboundPeers} + {GRPCMaxOpenConnections} + {MaxOpenConnections} + {Desired Concurrent Pocket RPC connections} + {100 (Constant number of wal, db and other open files)}
Breakdown:
ulimit -Sn: = is a soft number of open files that need to be open
GRPCMaxOpenConnections = is the number of RPC connections connections your node can relay
MaxOpenConnections = max number of connections you want your node to service
You will need to increase your ulimit to the calculated number. To do so, go into your .bashrc in your $HOME dir and enter:
ulimit -Sn 16384
Once you save your file, enter:
source ~/.bashrc
What do I do if my node needs to go down for an extended period, such as during a machine migration?
To opt out of being selected for work, you should deliberately jail your node, which lets the network know you are not ready to receive any relays. Once the machine is back up and running, you can unjail your node again.
Can I change the output address for my node when doing non-custodial staking?
You can’t edit an existing output address for your node stake. You will have to instead unstake your node and then restake with a different output address. Keep in mind that when you unstake, your staked POKT will be sent to the output address you originally set when staking your node, so make sure you have access to that account. Learn more about non-custodial staking.
Why don’t I see a transaction on the blockchain when I unstake my non-custodial node? How do I know my POKT is being sent to the output address?
Unstaking a node will not yield a separate transaction on the blockchain, so to verify that the POKT was sent to the output address, you will need to query the blockchain manually. Learn more.
Where do my staked funds go when I send a stake command?
When you send a stake command, your funds are moved to one of the protocol-owned account addresses responsible for managing aggregated staked funds, known as pools. There are separate pool addresses for staked nodes and apps.
The funds remain in the pool during the staking period. When you initiate an unstaking process, the funds are moved back from the pool to your staking account.
To check the pool balances, query pocket query supply using the CLI.
Node Troubleshooting
Why is my node not earning POKT?
See the section below on Maximizing your POKT earnings.
How do I check my Pocket node status?
Make sure your node is connected to the network by executing:
curl http://<your node ip>:26657/status
Lookout for latest_block_height and latest_block_time to make sure it’s updated to the current time in UTC.
I keep getting “too many open files” when my node is syncing? What does this mean?
This means that your ulimit is set too low on your node. Find instructions on how to set your ulimit above.
Why does my node keep crashing?
Your node can crash due to the following reasons:
Having too many open files: Make sure your ulimit is set correctly on your user profile. Find instructions on how to set your ulimit above.
Resource limitations: Make sure your node meets the minimum hardware requirements for both a Pocket node and the blockchain nodes you’re servicing. Details are above on this page.
Will my node be slashed for downtime?
There are negligible burns at this stage of the network, determined by the SlashFractionDowntime parameter. As the network matures, the rate will probably be increased to push for better service.
Maximizing your Pocket rewards
So you’ve spun up your Pocket node but you’re not earning as much as you thought you would. On this page, we debunk some common misconceptions and explain how to maximize your earnings.
My node is functional but doesn’t seem to be earning POKT - is it configured incorrectly?
There are a couple of reasons why your node may not be rewarding you with POKT. There are many great community members and Pocket teammates that are eager to help you triage this, but first, ask yourself, “is your node configured correctly?”. Don’t assume it is. Use the troubleshooting steps listed above.
The next thing to check is if your node is offline or jailed…or both. Reasons include:
If you suspect that this may be happening to your node, you can do a historical search on your nodes. We have a great community member who created this script to help you determine how long you were jailed for a specific period of time.
Checking your node status is one of the first steps towards maximizing your POKT earnings.
Conversely, how will I know if my node is working correctly?
Checking the block height is the easiest way to know if you’re synced up to the network. You can simply query your node to get this height and compare it to the latest block displayed on the Explorer.
pocket query height
The above command tells you if your Pocket node is synced up, but you’re probably running at least one other node for the external blockchains (referred to on this page as blockchain data nodes) that you’re serving to apps. You should make sure these are also synced up to their respective networks.
For example, you can check the block height of your Geth Ethereum node by submitting this query to your node, which returns the latest height of geth-mainnet known by the node.
To check if you’re earning rewards, you can simply monitor the balance of your node.
pocket query balance <address>
This way is very manual and you would need to track your balance over time to understand the change in the amounts.
The good news is there are several options for tracking your node rewards such as POKT ROKT, which tracks the last 24 hours of earnings in its CLI dashboard, or Sandwalker which tracks historical rewards by day and month.
Why don’t I just connect my Pocket node to [insert third-party provider here]?
On the surface, this seems like a great idea. Use a free tier of another service (e.g. Infura) and you don’t have to pay for any blockchain data node costs.
First off, free tiers by third-party providers are capped, which limits your upside. To make matters worse, if you use a third-party provider instead of running your own blockchain data node, you won’t make enough POKT to cover the server costs of your Pocket node.
Plus, that doesn’t jive with our ethos now, does it?
Why wouldn’t I make enough POKT with a third-party?
Using third-party providers slows you down. Slower nodes make less revenue.
Why does the third-party slow you down? Increasing the distance between your Pocket node and the third-party blockchain data node increases the number and length of hops that an end-user’s request has to make.
Here is an illustration:
In this example, the Pocket nodes (pink) are on the other side of the US from the Blockchain data nodes (orange). The end-user is using the Portal to communicate with the network. The path the end-user’s request must take is: End-user → Portal → Pocket Node → Blockchain Data Node → Pocket Node → Portal → End-user
The end-user’s request must hop back and forth across the US 4 times and that’s not including the hops between the user and the Portal. As a result, it may take up to 1 second for a user to receive something as simple as a balance query. That’s not very good service.
Aren’t there data centers around the world for this exact reason?
Correct. However, this works against you in this scenario.
Most third-party providers will have their servers in standard cloud regions situated around the world labeled such as East, West, EU, and Singapore. Load balancers are standard. For example, if a user is in Australia, they will be redirected to the nearest server in Singapore.
The challenge with using a third-party provider for your blockchain data node is that, by default, your Pocket Node will not always be in the same data center or machine as the third-party blockchain data node. If your Pocket Node is in US West, while you may have lesser latency from users who are hitting those servers, your node will never be as fast as it could be.
Your node will likely be in a different datacenter, where even a couple of hops will add somewhere between 30ms - 50ms. This becomes exacerbated when a user is coming from US East or the EU. With a full node on US West, you’re adding up to 200ms per request for these users.
Why does the latency matter?
While Pocket Network doesn’t discriminate (yet) between the speed of requests, the Portal does. The Portal filters out slow nodes to ensure the protocol is providing the best service possible to apps.
The vast majority of the requests on the network today come through the Portal. This means that faster nodes = more POKT.
In the long run, your setup matters not only for your earnings but also for ensuring a quality service for end-users (which will ultimately be crucial for the growth of the network).
Then how can I maximize my node revenue?
The following are some best practices that will give you an edge over the majority of node runners.
Know where the users are located… and locate your nodes accordingly. The Pocket Portal is currently in US-West-2, US-East-2, EU-West-1, AP-SE-1. The most underserved geographic area on Pocket is currently the Asia Pacific region.
Minimize the distance between your Pocket Nodes and your blockchain data nodes. Having your blockchain data nodes next to your Pocket nodes in the same rack is ideal.
Load-balance your blockchain data nodes.
Use a Peering Tower to reduce P2P gossip on the network. Visit the 🤖node-runner channel on Discord for more information.
Use physical hardware at home or data centers; you will have faster nodes and lower costs over time by owning your hardware and co-locating it.
Monitor your nodes for both health and sync – being online is only the first step, you must keep your blockchain data nodes in sync or they will not service relays.
Use services like the Performance Explorer to monitor your node’s performance in comparison to other nodes.
Why does the balance of an address change when there are no transactions in a given block?
This happens when an address is also a Validator. Validators earn block rewards when they are a proposer for a given block. Block rewards aren’t claimed through transactions, but instead are sent directly to the address.
This is inherited behavior from Tendermint and the Cosmos SDK, from which Pocket was originally derived. It is considered “core business logic” for the chain, and therefore does not need to be a transaction. That said, there are plans to change this behavior in v1 to increase transparency and visibility into block rewards.
To see how this works, take the address 85efd04b9bad9da612ee2f80db9b62bb413e32fb. At block height 4406, the balance for that address was 1848.257793 POKT, as you can test below using cURL (or using the API docs):
You can verify that there are no transactions associated with that address in block 4406.
Note
There isn’t a straighforward way to do this natively within Pocket at the moment. You would have to query all of the transactions for a given block and then search through them for the address in question. We plan to make this easier in the future.
Finally, you can see that this address was the proposer for block 4406:
So in this case, the balance of the address is altered, but without a visible transaction.
Node Tutorials
This section contains tutorials for various actions a typical node user may wish to undertake.
The following tutorial, Zero To Node, wlil show you a step-by-step way to set up a Pocket Node on hosted hardware.
Zero To Node
Welcome to Zero To Node! This is a step-by-step guide for setting up a Pocket node. While there are many different ways to set up a node, the focus of this tutorial is on keeping things simple and with the minimum of steps, while still focusing on security and stability.
The main utility of a Pocket node is to relay transactions to other blockchains. So, Pocket nodes need access to other nodes for the blockchains they’ll be relaying to. However, the focus of this guide is just on setting up a Pocket node that will relay to the Pocket network, essentially, through itself. Setting up nodes for other blockchains such as Harmony, Ethereum, or any of the other supported blockchains is beyond the scope of this guide.
After completing the steps outlined here, you’ll have a fully functional Pocket node up and running. If you choose, you can also opt to stake your node and earn rewards. We’ll cover that here, but staking is not required unless you want to earn rewards.
Who is this guide for?
This guide is for anyone interested in running Pocket nodes. While the goal is to keep things simple, the assumption is that you have some general blockchain and computer networking knowledge, and some Linux terminal experience.
What you’ll need
In order to complete this guide, you’ll need:
A server connected to the internet
A domain name
The ability to add DNS records for your domain
15,100 POKT (if you want to stake your node)
About 2-4 hours to complete and test everything
Part 1 – Server setup
This section will help you set up and configure a server to prepare it for being a Pocket node.
Setup a server
The first thing you’ll need to run a Pocket node is a server. For this guide, we’ll be using a virtual machine on the Linode cloud service, but you can use any cloud service you like, or run a server of your own.
Info
Pocket has no affiliation with Linode and does not recommend any one provider over another. The general steps outlined here should work for most cloud providers.
Let’s start by creating a Linode instance (a virtual machine).
The Pocket blockchain is very large and growing all the time, and the snapshot we’ll be downloading in a later step is too large to fit on this Linode instance.
Because of this, we’ll need to create a secondary storage volume. We recommend a size of at least 500GB, but as this requirement will keep growing, a larger volume size (or a dynamically adjustable disk size) will be important.
In your Linode account, click Volumes and then Create Volume.
Create a volume with the following specifications:
Label: poktuserdir
Size: 800GB
Region: [Same as your instance]
Linode: pokt001
Configure DNS
Now that the Linode instance is created and running, you’ll need to set up a DNS record that points to the IP address of the Linode instance.
Pocket nodes require a DNS name. DNS (Domain Name Service) names are used to map an IP address to more human-friendly names. So rather than referencing a server with an address like 134.23.153.21 we can use a name like pokt001.pokt.run.
Info
Most domain registrars allow you to add DNS records. Please refer to the DNS setup documentation for your provider.
Specifically, you’ll need to add an A record for the domain name. For the exact steps, consult the DNS documentation for your provider. Then create a record with the following information:
Name: pokt001
Type: A
Value: [Linode_IP_Address]
TTL: 300
After setting up your DNS record, wait a few minutes for the DNS to propagate. Then use the following command to check that the DNS record is working:
Info
The examples in this tutorial will use pokt001 as the server on the pokt.run domain, so pokt001.pokt.run will be used as the DNS name. Please replace this throughout with your own server and domain name.
ping -c 3 pokt001.pokt.run
You should see a response that looks something like this:
64 bytes from 134.23.153.21: icmp_seq=0 ttl=47 time=92.403 ms
64 bytes from 134.23.153.21: icmp_seq=1 ttl=47 time=142.828 ms
64 bytes from 134.23.153.21: icmp_seq=2 ttl=47 time=182.456 ms
If the IP address matches the IP address of your Linode instance, you’re all set!
Info
It can sometimes take longer than a minute for the DNS to propagate. So, be patient if things don’t seem to work right away.
Login with SSH
Now that we have a DNS record setup, we will look at using SSH to log in and continue the setup process.
The Secure Shell Protocol (SSH) is a secure way to connect to your Linode instance from a remote machine, like your local computer. We’ll be using SSH to complete the remainder of the setup process.
SSH from Mac or Linux
If you’re using a Mac, or Linux, on your local computer, you can SSH into your node by doing the following:
Open a terminal
SSH into your node using the following command:
ssh root@pokt001.pokt.run
Info
Don’t forget to replace pokt001.pokt.run with your DNS name.
You’ll be prompted for your password. This is the root password that you set when you created your Linode.
SSH from Windows
Windows 10 and later have a built-in SSH client. You can use SSH on Windows by doing the following:
Open the Windows terminal
SSH into your node using the following command:
ssh root@pokt001.pokt.run
Info
Don’t forget to replace pokt001.pokt.run with your DNS name.
If you’re using an older version of Windows, you might need to install PuTTY or some other SSH client.
Set the hostname
At this point you should be logged into your node as the root user.
In a previous step, we set the DNS name for the node. Now we’ll use the same name for the hostname on the server.
To set the server hostname use the following steps:
Open the /etc/hostname file with the following command:
nano /etc/hostname
Change the localhost value to the fully qualified hostname of your node (for example, pokt001.pokt.run).
Save the file with Ctrl+O and then Enter.
Exit nano with Ctrl+X.
Reboot the server with the following command:
reboot
Wait for the server to reboot then ssh back in as the root user before continuing on.
Create a Pocket user account
For security reasons it’s best not to use the root user. Instead, it’s better to create a new user and add the user to the sudo group.
To create a new user, enter the following commands:
Create a new user named pocket, add it to the sudo group, and set the default shell to bash. If you want to specify the location of the home directory, you can use the -d option followed by the path to the home directory:
For the rest of this guide, we’ll be using the pocket user. So now that the pocket user is created, you can switch from using root to the pocket user with the following command:
su - pocket
Mount the volume
Next we want to mount the secondary storage volume that we created in a previous step.
Verify that the volume is attached to your instance.
Many Pocket commands assume a data directory path of ~/.pocket. While it is possible to specify a different data directory with every command, it will be much easier to change the location of the pocket user home directory. For this tutorial, we will be putting the Pocket data directory at /mnt/data/.pocket.
To change the home directory of the pocket user:
sudo usermod -d /mnt/data pocket
Configure SSH Key Login (Optional):
While not required, using an SSH key provides a more secure means of accessing your server.
Using an SSH key removes the ability for credentials to be sniffed in the login process, and removes the pitfalls that can often come with user generated passwords since the key will truly be random.
One important thing to understand, is that without access to the ssh key, you won’t be able to log into your node. If you intend on accessing your node from multiple computers, it’s recommended that you repeat the Generate Key and Upload Key steps from each computer that you intend to access your node from before moving on to the Disable Root Login and Password Authentication step.
Log Out
At the terminal you’ll need to enter the logout command twice. The first logout logs you out of the pocket user, back to the root user, and the second logout logs you out of the server and back to your terminal.
Generate Key
Next, we’ll generate an ssh key. To do that you’ll run the ssh-keygen command. You’ll be prompted to specify the file you want to save the key to, and for a password. Specifying a password means that if someone has access to your key, they’d still need to know the password to be able to use it to login. To create the key, do the following:
Run the ssh-keygen command
ssh-keygen -t rsa -b 4096
Enter file in which to save the key (~/.ssh/id_rsa)
Enter a passphrase (empty for no passphrase)
Enter same passphrase again
The results should looking something like the following:
The key fingerprint is:
SHA256:jr2MLXIha188wYsp/bNflN9BuqQ3LWCAXJNTtHO7sWk
The key's randomart image is:
+---[RSA 4096]----+
| o+o |
| . oo. . |
| o ..o . . |
| . . o.+ |
| S oo= . |
| ...B o..+.B..|
| .o=.B ..E...|
| +.o*.o .o o |
| . +o.*+. |
+----[SHA256]-----+
Upload Key
Now we’re going to upload the key so that we can use it to log into the pocket user. If you choose a different path for the ssh key, it’s important to replace the ~/.ssh/id_rsa with the key you used.
Windows users may not have access to this command. If you don't have access to a Bash shell, you can use PowerShell to mimic this command. [See these instructions for more details.](https://chrisjhart.com/Windows-10-ssh-copy-id/)
Disable Root Login and Password Authentication
Now we’re now going to configure ssh to no longer allow root logins, and to not allow any password based login attempts. Meaning without access to the ssh key for the pocket user, no one will be able to log into the server.
First we’ll need to log back into the server:
ssh pocket@pokt001.pokt.run
From there, we’ll want to open the /etc/ssh/sshd_config file to make some changes to the default configuration:
sudo nano /etc/ssh/sshd_config
Once there, we’ll need to find and change the following lines:
#PermitRootLogin prohibit-password -> PermitRootLogin no
#PasswordAuthentication yes -> PasswordAuthentication no
Once changed, Ctrl-O followed by Enter will save the changes, and Ctrl-X will exit nano back to the terminal.
Then we’ll need to restart the ssh server for these changes to take effect:
sudo systemctl restart sshd.service
Verify Everything Works
The last step is to log out of the server, and try logging back in. If you’re no longer prompted for a password, then everything is working as expected.
That’s it for the server setup! Continue on to install the necessary software.
Part 2 – Software installation
This section will help you install all the necessary software for your node.
Install dependencies
Now let’s move on to the Pocket CLI installation.
At this point you should be logged in via SSH as the pocket user that we set up in a previous step. Before we install the Pocket software, we need to update the existing system packages and add a few dependencies.
Updating system packages
Update the repository index with the following command:
sudo apt update
Update the distribution with the following command:
sudo apt dist-upgrade -y
After the update completes, we’re ready to install the dependencies.
Installing dependencies
There are a handful of dependencies but installing them won’t take long. Also, some might already be installed. So if one of the dependencies exists, you can just move on to the next one.
git
sudo apt-get install git -y
build tools
sudo apt-get install build-essential -y
curl
sudo apt-get install curl -y
file
sudo apt-get install file -y
nginx
sudo apt install nginx -y
certbot
sudo apt install certbot -y
python3-certbot-nginx
sudo apt-get install python3-certbot-nginx -y
jq
sudo apt install jq -y
Install Go
After installing the dependencies, there is one more dependency we’ll need to add, and that’s Go. Go (sometimes known as “Golang”) is the programming language that the Pocket software was written in.
We could install Go using apt, but we want to get the latest stable version which probably isn’t available by default in the apt repository. So, we’ll use the steps below to install Go.
Make sure you’re in the pocket home directory.
cd ~
Find the latest version of Go from https://golang.org/dl/ then download it with the following command. (Make sure to change the link below to point to the correct version of Go.)
You may see a warning about being in a “detached HEAD” state. This is normal.
Build project code:
go build -o $GOPATH/bin/pocket $GOPATH/src/github.com/pokt-network/pocket-core/app/cmd/pocket_core/main.go
Test that the build succeeded:
pocket version
AppVersion: RC-0.9.2
That’s it for the software installation. Now let’s move on to the Pocket core configuration.
Part 3 – Pocket configuration
This section will help you configure your instance of Pocket.
Download snapshot
Rather than synchronizing your Pocket node from block zero (which could take weeks), you can use a snapshot. A snapshot of the Pocket blockchain is taken every 12 hours and can be downloaded using the instructions on the Pocket Snapshots Repository page.
Info
As of this writing, the snapshots are refreshed every 12 hours. In the GitHub repo you can look at when the README.md file was last updated to determine when the last snapshot was taken. It’s best to download the snapshot that is less than a few hours old.
Downloading a snapshot will likely take a few hours, so we’re going to use the screen command so that the download can run in the background, allowing you to perform other tasks.
To download the most recent snapshot:
Create a screen instance:
screen
Press Enter to get back to a prompt.
Change into the .pocket directory.
cd ~/.pocket
Create a directory named data and change into it:
mkdir data && cd data
Download the latest snapshot using the following command:
wget -qO- https://snapshot.nodes.pokt.network/latest.tar.gz | tar xvfz -
While the snapshot is downloading, press Ctrl-A and then d to let the process run in the background and be returned to a prompt.
To return to your screen instance to see how things are going:
screen -r
You can also check on the status of the download by watching your disk usage:
df -h
Once your download is completed, make the pocket user the owner of the data directory:
sudo chown -R pocket ~/.pocket/data
And when you’re done with your screen instance, you can exit out of it:
exit
Create a Pocket wallet account
Pocket nodes are associated with a Pocket wallet account. This is the account that will be used to send and receive transactions from the node. You can either create a new account using the Pocket CLI we just installed, or you can use an existing account. For this guide, we’ll be creating a new account.
Creating an account
To create an account, run the following command:
pocket accounts create
You’ll be prompted to set a passphrase for the account. You can use any passphrase you like but for security reasons, it’s best to use a passphrase that is at least 12 characters long, preferably longer.
Info
If you already have a Pocket account that you’d like to use to run the node, you can import it here. Upload the JSON file associated with your account to the server and run the following command:
pocket accounts import-armored <armoredJSONFile>
You will be prompted for the decryption passphrase of the file, and then for a new encryption passphrase to store in the keybase.
Listing accounts
After you’ve created the account you can use the pocket accounts list command to confirm that the account was added successfully.
pocket accounts list
Setting the validator address
Next, set the account as the one the node will use with the following command:
Finally, you can confirm that the validator address was set correctly by running the following command:
pocket accounts get-validator
Create config.json
The Pocket core software uses a config file to store configuration details. By default the config file is located at ~/.pocket/config/config.json. In this step we’ll look at how to create a new config file.
To create a new config file:
Run the following command, which will create the default config.json file, add the seeds, set port 8081 to 8082, and increase the RPC timeout value:
Pocket nodes relay transactions to other blockchains. So, you’ll need to configure the chains your node can relay to. For this guide, we’ll just be setting up our node to relay to the Pocket mainnet blockchain, essentially through itself.
To maximize your rewards, you’ll want to relay to other chains. We’ll cover that in more detail later but here is a list of other blockchains you could relay to.
Generating a chains.json file with the CLI
You can use the Pocket CLI to generate a chains.json file for your node by running the following command:
pocket util generate-chains
This will prompt you for the following information:
Enter the ID of the Pocket Network RelayChain ID:
0001
Enter the URL of the local network identifier.
http://127.0.0.1:8082/
When you’re prompted to add another chain, enter n for now.
Info
By default the chains.json file will be created in ~/.pocket/config. You can use the --datadir flag to create the chains.json file in an alternate location. For example: pocket util generate-chains --datadir "/mnt/data/.pocket".
Create genesis.json
Now that we have a chains.json file set up, so we can move on to test our node.
When you start a Pocket node for the first time, it will need to find other nodes (peers) to connect with. To do that we use a file named genesis.json with details about peers the node should connect to get on the network.
To create a JSON file with the genesis information:
Change to the .pocket/config directory:
cd ~/.pocket/config
Use the following command to get the genesis.json file from GitHub:
Ubuntu and other UNIX-like systems have a ulimit shell command that’s used to set resource limits for users. One of the limits that can be set is the number of open files a user is allowed to have. Pocket nodes will have a lot of files open at times, so we’ll want to increase the default ulimit for the pocket user account.
Increasing the ulimit
Before increasing the ulimit, you can check the current ulimit with the following command:
ulimit -n
Increase the ulimit to 16384. The -Sn option is for setting the soft limit on the number of open files:
ulimit -Sn 16384
Check the new ulimit to confirm that it was set correctly. The -n option is for getting the limit for just the number of open files:
ulimit -n
Permanent settings
Using the above method for setting the ulimit only keeps the change in effect for the current session. To permanently set the ulimit, you can do the following:
Open the /etc/security/limits.conf file.
sudo nano /etc/security/limits.conf
Add the following line to the bottom of the file:
pocket soft nofile 16384
Save the file with Ctrl+O and then Enter.
Exit nano with Ctrl+X.
After permanently setting the ulimit, the next thing we’ll do is download a snapshot of the Pocket blockchain.
Configure systemd
Next, we’ll configure the Pocket service using systemd, a Linux service manager. This will enable the Pocket node to run and restart even when we’re not logged in.
Creating a systemd service in Linux
To setup a systemd service for Pocket, do the following:
Open nano and create a new file called pocket.service:
Make sure the User is set to the user that will run the Pocket service.
Make sure the ExecStart and ExecStop paths are set to the path for the Pocket binary.
Save the file with Ctrl+O and then return.
Exit nano with Ctrl+X.
Reload the service files to include the pocket service:
sudo systemctl daemon-reload
Start the pocket service:
sudo systemctl start pocket.service
Verify the service is running:
sudo systemctl status pocket.service
pocket.service - Pocket service
Loaded: loaded (/etc/systemd/system/pocket.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-10-07 00:07:05 UTC; 1 weeks 0 days ago
In case you skipped the step above while the snapshot was downloading, once your download is completed, make the pocket user the owner of the data directory:
sudo chown -R pocket ~/.pocket/data
And when you’re done with your screen instance, you can exit out of it:
exit
We’re just about done. We just need to setup an HTTP proxy and we’ll be ready to go live. We’ll setup the proxy next.
Part 4 – Proxy configuration
This section will help you set up the proxy setting on your node.
Setup SSL
Pocket requires that nodes have an SSL certificate for secure communications. SSL (Secure Sockets Layer) is a layer of security that sits on top of TCP/IP. It’s used to encrypt the data sent between a client and a server. To use SSL, you need to have a certificate and a key. Thankfully, getting an SSL certificate is straightforward and free.
To get a certificate, we’ll be using Let’s Encrypt which is a service that issues SSL certificates for free. We’ll also be using software called certbot to register, install, and renew the certificate.
Registering an SSL certificate
We installed certbot in a previous step so we just need to use it to request a certificate.
To get a certificate, we’ll need to use the certbot command with the following options:
--register-unsafely-without-email: This option is required to get a certificate without an email address.
--agree-tos: This option is required to agree to the Let’s Encrypt Terms of Service.
--nginx: This option is required to use the nginx plugin.
--no-redirect: This option is required to disable the redirect to the Let’s Encrypt website.
--domain: This option is required to specify the domain name.
Here’s an example of how to request a certificate. Just replace $HOSTNAME with the DNS name of your node:
The output from this command should confirm that the certificate was successfully registered.
Testing your certificate
To be sure, you’ll also want to test that the certificate is working.
There is a command that certbot provides to test your certificate. It’s used for testing the auto-renewal of the certificate but it also confirms that the certificate is working. You can run it using the following command:
sudo certbot renew --dry-run
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/pokt001.pokt.run/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The resulting output should confirm that the certificate is working.
Configure Nginx
Nginx is a web server. We installed it in a previous step but we need to do some additional configuration.
Nginx uses config files to define servers and routes for incoming requests. For Pocket nodes, nginx needs to relay public requests to a local HTTP server that pocket core is running. This is referred to as the proxy. We’ll also need to proxy requests made by the Pocket CLI. For example, when we run the command pocket query height, the CLI makes an http request to the node’s local HTTP server.
Config files
The nginx configuration files we’re interested in are located in the /etc/nginx/sites-available/ directory. In that directory there is a default configuration file named default. This is the configuration that is created when you install nginx, but we’ll be creating our own for our node.
To configure nginx:
Confirm the name of your SSL certificate:
sudo ls /etc/letsencrypt/live/
Create a new config file with nano:
sudo nano /etc/nginx/sites-available/pocket
Add the following code, making sure to change the hostname values (pokt001.pokt.run) to your node’s DNS hostname in the three places found below:
We’re almost done, but before we finish we’ll make our server more secure by setting firewall rules to limit network exposure. The Uncomplicated Firewall (UFW) is a security tool that makes configuring the firewall reasonably simple. We’ll use it to disable unnecessary ports.
Ports you need to open
For running a Pocket node, you’ll need to open the following ports:
22: SSH
80: HTTP
443: HTTPS
8081: For the Pocket HTTP API
26656: For the Pocket RPC API
Use UFW to disable unnecessary ports
To use UFW to configure the firewall:
Enable UFW. When prompted, press y to confirm:
sudo ufw enable
Set the default to deny all incoming connections:
sudo ufw default deny
Allow the SSH port:
sudo ufw allow ssh
Allow port 80:
sudo ufw allow 80
Allow port 443:
sudo ufw allow 443
Allow port 8081:
sudo ufw allow 8081
Allow port 26656:
sudo ufw allow 26656
That’s it for the UFW setup. Let’s just check the status to confirm the ports are open. To do that, run the following command:
sudo ufw status
After confirming only the necessary ports are open, you can move on to the final steps.
Part 5 – Going live
This section will details the final steps in going live with your node.
Test everything
At this point your Pocket node should be up and running!
But you’ll want to test it to confirm. The following are some of the things you can do to test your Pocket Node.
Make sure the Pocket process is running
The first thing to check is that the pocket service is running. You can do that by running the following command:
You’ll want to check that the node is fully synced with the Pocket blockchain. The easiest way is to run the following command:
pocket query height
The result should look something like the following.
{"height": 48161}
Network status
Another way to see if your node is fully synced is to check the status with the following command:
curl http://127.0.0.1:26657/status
The result should look something like the following. Note the highlighted property catching_up which indicates if the node is catching up with the blockchain or fully synced. In the example below, the node is fully synced.
You’ll also want to make sure your node is accessible to other nodes.
To test and confirm your node is visible to other nodes on the public network, you’ll make an HTTP request using the public DNS name for the node. You can use the following command to make that request:
curl https://pokt001.pokt.run:8081/v1
Info
As always, don’t forget to change pokt001.pokt.run to the DNS name for your node.
This should return the following. This is the version of pocket-core that is running.
"RC-0.9.2"
Staking your node
To earn POKT rewards, you’ll need to stake at least 15,000 POKT. That said, you should stake at least 15,100 POKT or more to be safe. This provides a little extra room in case your node gets slashed (penalized) for some reason.
Warning
Please make sure that you understand the risks associated with staking POKT and running a Pocket node.
If you’re using the Pocket CLI to fund an account, keep in mind that the CLI uses uPOKT (the smallest unit of POKT) for its calculations. The formula for converting POKT to uPOKT is: uPOKT = POKT * 10^6. So, multiplying 15050 POKT by 10^6 (one million) will result in 15050000000 uPOKT.
Also keep in mind that there is a cost for every transaction you send. At the moment, that cost is a flat fee of 0.01 POKT, or 10000 uPOKT, but this may be subject to change.
List your accounts:
pocket accounts list
Confirm the validator account is set:
pocket accounts get-validator
Confirm the validator account has enough POKT. This should be at least 15,101 POKT. You’ll want 15,100 to stake and a bit more for network fees:
pocket query balance [YOUR_VALIDATOR_ADDRESS]
Stake your node, making sure to enter the correct details for your setup:
The [CHAIN_IDS] placeholder should be a list of relay chain IDs that are defined in your ~/.pocket/config/chains.json file. In this guide we only set up 0001, but if you were relaying to multiple chains, each id would be separated by a comma. For example, 0001,0022,0040.
Info
As of RC-0.9.1.3 there are two staking methods: custodial and non-custodial. The custodial method is used in the example above.
After you send the stake command, you’ll be prompted for your passphrase, then you should see something like this:
The actual time it takes to stake will vary depending on when the last block was processed, but generally, it should take less than 15 minutes.
Confirm your node is live
After you’ve staked your node, you can confirm it’s live by running the following command:
pocket query node [YOUR_VALIDATOR_ADDRESS]
If you see something like the following, it just means your node is not live yet:
http://localhost:8082/v1/query/node
the http status code was not okay: 400, and the status was: 400 Bad Request, with a response of {"code":400,"message":"validator not found for 07f5084ab5f5246d747fd1154d5d4387ee5a7111"}
If this happens, please wait a few minutes and try again.
Tutorial complete
Congratulations! You’ve successfully set up a Pocket node.
There’s more to running a Pocket node than this, such as maintenance, upgrades, and other administrative tasks, but hopefully this has gotten you started and on the right path. Thank you for doing your part to help decentralize Web3!
Integrate
SDKs
Here are some SDKs for interacting with Pocket:
PocketJS - JavaScript client SDK for interacting with Pocket Network.
pypocket - Python client SDK for interacting with Pocket Network.
pocket-go - Go client SDK for interacting with Pocket Network.
Accounts and Transactions
The Native POKT Blockchain Token
POKT is the native token of the Pocket Blockchain. Its lowest, indivisible unit is uPOKT.
POKT and uPOKT
POKT is a 6 decimals token: 1*10^6 uPOKT = 1 POKT
All numbers displayed through RPC calls on the Pocket blockchain are displayed in uPOKT, and all transactions use uPOKT.
The simplest way to generate new accounts, or addresses, on the POKT blockchain is to use the official Pocket client, PocketJS.
Creating a New Account
To create a new account on the POKT blockchain and export it:
import { Pocket } from'@pokt-network/pocket-js'// PocketJS must always be initialized with at least one dispatcher.
constPOCKET_DISPATCHER='<URL_TO_DISPATCH_NODE>'constpocket=newPocket(POCKET_DISPATCHER)
// The passphrase used to encrypt the private key while in memory:
constPASSPHRASE='foobar'constaccount=awaitpocket.keybase.createAccount(PASSPHRASE)
// The result of successful account creation:
console.log(account)
// Using the exportAccount function, you can obtain a plaintext private key.
constexportedAccountPrivateKey=awaitpocket.keybase.exportAccount(
account.address.toString('hex'),
PASSPHRASE)
// This plaintext private key should be encrypted before storage.
console.log(exportedAccountPrivateKey.toString('hex'))
// You can also export an encrypted JSON version of the same private key.
// The passphrase used to encrypt this JSON file is separate from the
// previous PASSPHRASE.
constexportedPPK=awaitpocket.keybase.exportPPK(
exportedAccountPrivateKey,
// The PPK passphrase used to encrypt the JSON file
'foo',
// A hint for the PPK passphrase
'what comes before bar')
console.log(exportedPPK)
Importing an Existing Account
To import an existing account using either the raw private key or the encrypted JSON PPK:
import { Pocket } from'@pokt-network/pocket-js'// PocketJS must always be initialized with at least one dispatcher.
constPOCKET_DISPATCHER='<URL_TO_DISPATCH_NODE>'constpocket=newPocket(POCKET_DISPATCHER)
// The passphrase used to encrypt the private key while in memory:
constPASSPHRASE='foobar'constPRIVATE_KEY='...'// Import an existing account using the raw private key:
constimportedAccount=awaitpocket.keybase.importAccount(
PRIVATEKEY,
// The passphrase to encrypt the private key while in memory
PASSPHRASE)
// Import an account using the encrypted JSON PPK:
constimportedPPKAccount=awaitpocket.keybase.importPPK(
// The PPK passphrase used when the key was exported
'foo',
exportedPPK.salt,
exportedPPK.secParam,
exportedPPK.hint,
exportedPPK.cypherText,
// The passphrase to encrypt the private key while in memory
PASSPHRASE,
)
Verifying an Address
To verify a POKT blockchain address, public key, or raw private key:
import {
validateAddressHex,
validatePrivateKey,
validatePublicKey} from'@pokt-network/pocket-js'// Validate a POKT blockchain address: returns undefined if valid.
// This should be wrapped in a try / catch block as it will throw the
// appropriate error if the address is not valid.
try {
constisValidAddress=!(
validateAddressHex(account.addressHex) instanceof Error
)
} catch (e) {
// Handle the error
}
// Validate a public key: returns true or false.
constisValidPublicKey=validatePublicKey(account.publicKey.toString('hex'))
// Validate a private key: returns true or false.
constisValidPrivateKey=validatePrivateKey(privateKey)
Transaction Construction
Sending a Transaction
To send a transaction on the POKT blockchain:
import { Pocket } from'@pokt-network/pocket-js'constRECEIVER_ADDRESS='...'constSENDER_ADDRESS='...'constSENDER_PRIVATE_KEY='...'// The passphrase used to encrypt the private key while in memory:
constPASSPHRASE='foobar'// PocketJS must always be initialized with at least one dispatcher.
constPOCKET_DISPATCHER='<URL_TO_DISPATCH_NODE>'// To send a transaction, you can use one of the public RPCs or
// your own Pocket node.
constPOCKET_RPC='<URL_TO_RPC_NODE>'constpocket=newPocket(POCKET_DISPATCHER, POCKET_RPC)
// If you are using Pocket Mainnet, make sure to disable legacyCodec
pocket.configuration.useLegacyTxCodec=false;
// Create a transaction signer using the `withPrivateKey` method:
consttxSigner=pocket.withPrivateKey(
SENDER_PRIVATE_KEY)
consttransactionResponse=awaittxSigner.send(
// Origin address for the send
SENDER_ADDRESS,
// Receiver address
RECEIVER_ADDRESS,
// 10 POKT
'10000000' ).submit(
'mainnet',
// The transaction fee is always 10,000 uPOKT
'10000' )
// Check if the transaction returned an error:
if (typeGuard(transactionResponse, RpcError)) {
thrownew Error(transactionResponse.message)
}
// You will be able to look up this transaction through this hash after the
// next block clears.
const { hash } =transactionResponseconsole.log(hash)
Creating a Signed SEND Transaction Offline
To create a signed transaction that can be sent immediately or stored:
import { Pocket } from'@pokt-network/pocket-js'constRECEIVER_ADDRESS='...'constSENDER_ADDRESS='...'constSENDER_PRIVATE_KEY='...'// The passphrase used to encrypt the private key while in memory:
constPASSPHRASE='foobar'// PocketJS must always be initialized with at least one dispatcher.
constPOCKET_DISPATCHER='<URL_TO_DISPATCH_NODE>'constpocket=newPocket(POCKET_DISPATCHER)
// If you are using Pocket Mainnet, make sure to disable legacyCodec
pocket.configuration.useLegacyTxCodec=false;
// Create a transaction signer using the `withPrivateKey` method:
consttxSigner=pocket.withPrivateKey(
SENDER_PRIVATE_KEY)
// Now use the transaction signer to create a signed SEND transaction
consttxSignerWithSendTransaction=txSigner.send(
// Origin address for the send
SENDER_ADDRESS,
// Receiver address
RECEIVER_ADDRESS,
// 10 POKT
'10000000')
// Generate offline signed send transaction
constsendTx=awaittxSignerWithSendTransaction.createTransaction(
'mainnet',
// The transaction fee is always 10,000 uPOKT
'10000')
console.log('Offline signed send transaction:', sendTx)
After calling .sendTransaction(), you will get back a response with this format:
Calculate transaction hash from raw transaction bytes
constcrypto=require('crypto');
// This is the raw transaction bytes obtained from offline signed transaction
consttxHex='d1010a4....bf8970d'consttxHash=crypto.createHash('sha256').update(Buffer.from(txHex, 'hex')).digest('hex');
console.log(txHash)
Deserialize offline signed SEND transaction
You can also decode the raw transaction bytes generated offline (only works for SEND transactions):
// Only supported for versions >= 0.7.1
const { ProtoTxDecoder } =require('@pokt-network/pocket-js')
constENCODED_TX_BYTES=Buffer.from('d1010a4....bf8970d', 'hex')
constprotoTxDecoder=awaitpocket.withProtoTxDecoder()
constprotoStdTx=awaitprotoTxDecoder.unmarshalStdTx(ENCODED_TX_BYTES)
constdata=awaitprotoTxDecoder.decodeStdTxData(protoStdTx)
console.log('Deserialized transaction:', data)
Transaction Verification
Confirming that Funds have been Received
// The 64-character transaction hash is necessary to retrieve the transaction:
consttx=awaitpocket.query.getTX(hash)
if (typeGuard(tx, RpcError)) {
thrownew Error(tx.message)
}
// The retrieved transaction object:
console.log(tx)
The return code of the transaction must be 0 — indicating success:
Pocket Network is a pioneer in a new era of democratically-governed digital public goods. Our Decentralized Autonomous Organization (DAO) means that you, our community, will control all aspects of our protocol and ecosystem.
Pocket uses off-chain governance because it’s the most flexible and future-proof way for us to organize our DAO. For more on our reasoning behind this, check out our Lean Governance Thesis.
To learn how to earn a vote in the DAO and decide the future of Pocket Network, see the section on trophies.
Info
You don’t need a vote in the DAO to submit proposals or participate in discussions! Everyone is free to share their opinions. Head over to the forum to see what decisions are being debated.
All approved decisions get submitted to the blockchain by the Pocket Network Foundation, which is fully accountable to the DAO. To learn more about how this is, read the DAO Constitution and the Foundation’s Articles of Association.
Proposals
Submitting proposals to the DAO is pretty easy and anyone can do it.
There are 3 types of proposals:
PIP: Pocket Improvement Proposal
PEP: Pocket Ecosystem Proposal
PUP: Parameter Update Proposal
Posting your proposal to Discourse puts it up for consideration and debate by the DAO. To kickstart a vote, you need a voter to submit it to our governance dashboard on your behalf.
PIP – Pocket Improvement Proposal
Pocket Improvement Proposals (PIPs) include any proposals that aim to level up the Pocket Network ecosystem, through:
Upgrading the Pocket Network protocol
Upgrading the governance of the DAO and the Pocket Network Foundation
Adding/removing permission holders within the existing governance structure of the DAO
PIP votes will last 7 days and pass with Majority Approval (50% yes votes by participating voters) unless otherwise specified in the Constitution.
To submit a PIP, head to the forum here, then click New Topic to generate a template for your proposal.
PEP – Pocket Ecosystem Proposal
Pocket Ecosystem Proposals (PEPs) include proposals to distribute funds to or form agreements with Contributors to the Pocket Network ecosystem, in the form of:
Imbursements – payments for future work
Reimbursements – compensation for previous work
Bounties – rewards for work that don’t yet have specified workers
Transfers – transferring funds between DAO-owned accounts
Agreements – forming new DAO relationships, including non-financial in nature
Info
How is the DAO funded?
The DAO earns continuous revenue in the form of the DAOAllocation, which is a % that the DAO receives for every RelaysToTokensMultiplier minted in the block reward. This is proportional to the number of relays being processed for app developers, which means the more traction Pocket Network gets, the more wealthy the DAO becomes!
PEP votes will last 7 days and pass with Majority Approval (50% yes votes by participating voters) unless otherwise specified in the Constitution.
To submit a PEP, head to the forum here, then click New Topic to generate a template for your proposal.
Info
Does the DAO hold non-POKT tokens?
The DAO also holds non-POKT tokens as a result of token swaps and airdrops. Since the Pocket Network blockchain is not EVM-compatible, these assets are custodied by the Pocket Network Foundation in multi-sig accounts.
An RFP is a Request for Proposal. You would use this when you know that something is needed but you are unsure of exactly what the solution is or are unable to build it yourself. Posting an RFP should serve as a signal to other community members that there might be demand for their contributions.
For example, this Node Deployment Solutions RFP which led to the successful PEP (POKT grant) for an automated deployment tool called Node Pilot.
A PEP is a type of proposal that requests a POKT grant from the DAO treasury. You could get a POKT grant for contributions to the Pocket Network ecosystem.
All the issues are documented and tagged on Github, and the “starter task” tag can be used to filter for simpler issues to get you acquainted with the codebase.
All of these contributions are under the MIT license but may be partially rewarded by the scholarship fund. Larger contributions from repeat contributors will be evaluated by the DAO through separate proposals.
In addition to contributing to the future of Web3, you will also get mentorship and experience by working with the core Pocket team, as well as present and discuss your work in our weekly contributor hours.
Check out the #v1-research and #v1-dev channels in Discord to connect with the team.
Scholarships
The PEP-31 Scholarship Fund was approved by the DAO in June 2022 to allocate an accumulating monthly allowance of 10,000 POKT per month to contributors, students, learners, speakers, educators and others in the Pocket community.
Recipients
June 2022
Tyler Kell (@relyt29) is the first recipient of the Pocket Scholarship for his presentation Academic Cryptocurrency Research Space - An Overview, Spring 2022 at Infracon 2022 - Pocket’s inaugral conference.
The DAO onboarding process has been designed to assign governance powers to the most engaged, knowledgeable, and experienced members of the Pocket Network community.
The steps for obtaining a vote are as follows…
1. Get Qualified
First, you need to prove your knowledge of and participation in the Pocket Network by earning trophies.
There are four paths that you can take on this journey:
You will complete a series of quests and report your completion of these quests in the 🏆trophies channel in Discord. Follow the path guides above to see which quests are up next and how many you need to evolve.
Once you have evolved to the 3rd level of any path, you have qualified for a vote in the DAO. Type !qualify in the 🏆trophies channel to obtain the Qualified role.
2. Get Verified
If you want to be verified by our existing Voters, and obtain the Verified role, you must do both of the following:
Post a selfie to the #✅verify channel holding a piece of paper with your Discord username (e.g. username#1234) and the day’s date
Post a message to the #✅verify channel with the following template:
!verify
My favorite thing about Pocket Network:
Why I want to be a Voter:
Once you have done this, if existing Voters are comfortable you are not a malicious agent, they will approve you. If 33% of existing Voters approve you in the next 7 days, you’ll be officially verified and one step closer to obtaining your own vote in our DAO.
3. Claim Your Vote
Type !claim-vote in the 🏆trophies channel. This will only work if you got both the Qualified and Verified roles.
Then DM jackal to claim your POKTDAO token airdrop (our airdrop bot is currently out of commission).
Info
The token is non-transferable so you should choose a MetaMask or WalletConnect wallet that you’re happy holding the token in forever.
4. Vote and Subscribe
Vote in our governance dashboard by connecting the wallet you chose for your POKTDAO airdrop.
Subscribe to 📥proposals (click Follow) to make sure you don’t miss anything!
App Developers
Netizen
So you want to be a full-fledged Cyberpunk? Joining our elite is not for the faint of heart. You must first prove your worth as a Netizen by completing the following bounty and by providing evidence in the 🏆trophies channel on Discord.
To claim your new Netizen role once you’ve done this, type !become-netizen.
To verify the number of relays sent by you through the Portal, you need to send an email to jack at pokt dot network, using the same email you used to sign up for the Portal, with the subject as “Gateway Quest” and your applicationPublicKey in the body.
Savant
So you aren’t a poser! Now let’s see if you’re worthy to join the ranks of the Savants. To earn this title, you must complete at least 5 out of 9 of the following bounties, once again providing evidence in the 🏆trophies channel on Discord.
To claim your new Savant role once you’ve done this, type !become-savant.
Maintenance
Build your own tooling or have an approved PR on existing Pocket-related open-source application tooling.
Loadtest
Participate in load testing nodes with at least 1m relays in Pocket testnets.
QA
Create or contribute (non-grammatical) improvements to Pocket application technical documentation or open-source application tooling documentation.
Bootcamp-Dev
Create or contribute (non-grammatical) improvements to a guide on how to use Pocket for other app developers.
Mentor
Help another app developer get started using Pocket.
Torrent
This bounty is split into 4 parts, each worth 1 point towards your 5/9 target:
Send 2.5 million relays through Pocket Network.
Send 5 million relays
Send 7.5 million relays
Send 10 million relays
Qualified!
Once you’ve reached Savant, you’re now qualified for a vote in our DAO.
Cyberpunk
Well done Savant, we recognize the trials you have taken on and the skills you have acquired to reach this point. The bounties at this point are the ones that will build lasting resilience and autonomy for the future we seek to create. Complete all bounties from every rank of the App Developer path then submit the !become-cyberpunk command to enter the elite of the elite, the pantheon of Cyberpunks.
Token-Handler
Build tooling for AAT management and have 3 Verified Savants or Pocket core team members vouch for the tool’s quality.
Optimizer
Build tooling for optimizing app stake prices and have 3 Verified Savants or Pocket core team members vouch for the tool’s quality.
Founded
Create or take ownership of an application, SDK, or tool that is vouched for by at least 3 (BrightID) Verified Savants or Pocket core team members.
Ventured
Submit an application-oriented PEP and receive a POKT grant from the DAO.
Node Runners
Nodégé
Greetings aspiring Node Runner, we have heard your call to join us in the battle against the corporate node overlords. In order to earn the Nodégé rank, you must complete 3/3 of the following assignments, providing evidence in the 🏆trophies channel, then submit the !become-nodege command.
Then send your address, public key, and the signature that was generated by the command to the 🏆trophies channel.
Transmission
Successfully submit a proof transaction in Pocket testnet or mainnet.
Jailbreak
Avoid getting jailed for 7 days (672 consecutive blocks) in Pocket testnet or mainnet.
Nodemad
Congratulations Nodégé, lesser nodes have not made it this far, we are pleased with your progress. To earn the Nodemad rank, you must complete 5/8 of the following assignments, providing evidence in the 🏆trophies channel, then submit the !become-nodemad command.
Datacenter
Avoid getting jailed for 1 month (2880 consecutive blocks) in Pocket mainnet.
Broadcast
Submit successful proof transactions of 50k relays in Pocket mainnet.
Overseer
Help another community member set up their node.
Toolkit
Build and open source your own tooling or have an approved PR on existing Pocket-related open source node tooling.
Betakey
Participate in beta testing for a new Pocket Core version and submit the results of at least one useful test, as vouched for by the Pocket Core developers.
Document
Create or contribute (non-grammatical) improvements to Pocket node technical documentation or open source node tooling documentation.
Bootcamp-Node
Create or contribute (non-grammatical) improvements to a guide on how to run a Pocket node.
Upgrade
Upgrade your node before the DAO’s chosen upgrade height.
Qualified!
Once you’ve reached Nodemad, you’re now qualified for a vote in our DAO.
Node Runner
You’ve proven yourself a key member of our node army. Complete all assignments from every rank of the Node Runner path then submit the !become-node-runner command to cement your legacy in the pantheon of our greatest Node Runners.
Cloud
Avoid getting jailed for 3 months (8640 consecutive blocks), for at least 5 Pocket nodes, in Pocket mainnet.
Livestream
Submit successful proof transactions of 1M relays in Pocket mainnet.
Infrared
Submit an infrastructure-oriented PEP and receive a POKT grant from the DAO.
Testkit
Participate in beta testing for 3 Pocket Core versions (excluding the one you did for the Betakey quest) and submit the results of at least one useful test, as vouched for by the Pocket Core developers.
Satellite
Maintain a dispatch node and have 3 Verified Netizens or Pocket core team members vouch that they have included you in their dispatch list.
Seedbank
Maintain a seed node and have 3 Verified Nodégés or Pocket core team members vouch that they have included you in their seed list.
Relay-Station
Submit successful proof transactions of 50k relays in all whitelisted RelayChainIDs in Pocket Mainnet.
Community Shepherds
Farmer
Namaste aspiring Shepherd, we kindly thank you for your willingness to nurture this community into one that is regenerative and ripe with autonomous agents. While our allies in the Node Runner and App Developer paths are fortifying our outposts and advancing our objectives, the jobs on this ranch serve to replenish our ecosystem. To join the rank of Farmers, complete 6/8 of the following jobs, providing evidence in the 🏆trophies channel, then submit the !become-farmer command.
To verify that you used the app, screen record yourself submitting an on-chain action (e.g. submitting a transaction or querying chain data), with your Discord username somewhere on the screen, then share the screen recording to 🏆trophies when you report the quest completion.
Quick-Repair
Highlight (and fix where possible) inconsistencies/bugs or other improvements in Pocket’s website, documentation, social channels or content.
Bird-Seed
Tweet about Pocket in a meaningful way, retweeted by 3 Verified Shepherd’s or Pocket core team members.
Swarm
Identify and share 3 relevant (unshared) tweets that other Farmhands can respond to.
Dogfood
Confirm that you have used two community apps.
Info
To verify that you used the app, screen record yourself submitting an on-chain action (e.g. submitting a transaction or querying chain data), with your Discord username somewhere on the screen, then share the screen recording to 🏆trophies when you report the quest completion.
Seedling
Generate 1 unique idea for future iterations of the trophy system.
Leaflet
Create a Pocket meme and get at least 5 dab reacts from Verified Shepherd’s or Pocket core team members.
Fertilizer
Purchase Discord Nitro and boost Pocket Network’s community server.
Shepherd
At this point you have now familiarized yourself with the ways of the Farmers. Your studies at this level will seek to align you more deeply with the vision and mission that has brought us together. Completing 4/6 of the following jobs will earn you a flight to the Shepherd’s station. Provide proof of your work in the 🏆trophies channel, then submit the !become-shepherd command.
Infolink
Attend a Pocket workshop or community call.
Biomimicry
Make notes/takeaways from a Pocket workshop or community call.
Nanobee
Help to organize a Pocket workshop or community call.
Foraging
Collect and organize user feedback/questions for the Pocket core team.
Cultivation
Mentor anyone into achieving the Farmer rank.
Path-of-Least-Resistance
Create educational content for Pocket.
Qualified!
Once you’ve reached Shepherd, you’re now qualified for a vote in our DAO.
Regen
“De lo mio”, Shepherd. In our homeland, this term of endearment means “one of mine”. Because you have made it here, we consider you to be one of our closest allies in a mission yet unfulfilled. But there is little time for frivolities, the enemy has expanded into the farthest reaches of Web3 and we must continue to cultivate the lands upon which our node and dev allies will fight them. The work of Shepherds requires the softest of touches, as you will be venturing out to guide others towards the regenerative path of true decentralization. Complete every job in all ranks of the Community Shepherd path then submit the !become-regen command to earn enlightenment in the pantheon of Regens.
Telepathy
Create meaningful content about Pocket Network, vouched for by 3 Verified Shepherd’s or Pocket core team members.
Topographics
Translate content on Pocket’s website, blog or docs.
Wool-Clipper
Successfully onboard an app developer into Pocket Network.
Shepherds-Crook
Successfully onboard a node runner into Pocket Network.
Sheep-Dog
Successfully onboard 5 node runners into Pocket Network.
Seed-Fund
Submit a community-orientated PEP and receive a POKT grant from the DAO.
Assurance
QA and document a Pocket library, product or pre-release.
Governor/Contributors
Biohacker
Greetings fledgling DAOist and aspiring Biohacker. It is now time to augment your skills via the cybernetic system, Pocket DAO, to truly enhance this community’s mission. You will be considered a true Biohacker if you acquire 2/3 of the following augments, providing evidence in the 🏆trophies channel, then submit the !become-biohacker command.
This quest can’t be completed currently because our proposal challenge system isn’t live yet.
Cyborg
We’re impressed with your augmentation capabilities, but to truly become a Cyborg you’ll need to acquire 3/5 of these augments, providing evidence in the 🏆trophies channel, then submit the !become-cyborg command.
Cybernetic-Arm
Author a successful PIP (independent of the Anode quest).
Cybernetic-Leg
Author a successful PUP (independent of the Anode quest).
Implanted-Rebreather
Author a successful PEP (independent of the Anode quest).
Feedback-Loop
Author a successful constitutional amendment.
Regulated-Nervous-System
Join the Aragon Court.
Warning
This quest can’t be completed currently because Aragon Court isn’t live yet.
Singularity
Qualified!
You’re now qualified for a vote in our DAO. Follow the rest of the steps outlined here to claim your vote:
So you have ventured where few still dare to go. Your current augments allow for deeply integrated communications with our cybernetic organization. Acquire every augment from all ranks in the Governor path then submit the !become-singularity command and you may just unlock infinite power… The Singularity is near…
Nanobots
Author 3 successful PEPs (independent of previous quests).
Machine-Learning
Author 3 successful PUPs (independent of previous quests).
Artificial-Intelligence
Author 3 successful PIPs (independent of previous quests).
Quantum-Resistance
Author 3 constitutional amendments (independent of previous quests) or successfully challenge 3 actions.
Warning
The latter option of this quest can’t be done currently because our proposal challenge system isn’t live yet.
Contribute to the Docs
We encourage community contributions to our documentation. Help us improve!
If you see something in these pages that is incorrect or outdated, or if there is a section that’s missing that you would like to author, our goal is to empower you to help make these changes and additions.
This section will show you how to make changes to this documentation.
If you have experience with editing documentation stored in a repo on GitHub, the Quick setup (below) will probably be sufficient. For everyone else, please read the full Contributors Guide.
Quick setup
If you do have a basic familiarity around using command line tools and GitHub,
then the process can be summarized down to the following steps.
Install Hugo; Make sure the version is 0.93 or newer.
From the root of the repository, run hugo serve, and open http://localhost:1313 in a browser.
In a text editor, make any desired changes to the Markdown files inside the content/ directory.
Save the files as you edit and the changes will be displayed in realtime in your browser.
When you have the desired result, commit your changes to a new branch and submit a pull request.
A member of the Pocket team will review the Pull Request, and may ask you to submit some revisions. If all looks good, your changes will be committed to the repo.
If you need more details about this process, please read the full Contributors Guide.
Contributors Guide
This page will go into detail on how to contribute to the Pocket Network documentation site at https://docs.pokt.network. If you are familiar with Markdown and contributing to an open-source repo on GitHub, the Quick setup section may be all you need.
Required installations
There are only 2 tools needed to get started contributing to the documentation:
For this guide, we’ll cover the easiest way to install Hugo, which is
downloading an already built executable. If you would prefer to install from a
package manager like brew, chocolately, or apt, then you should follow
along with the corresponding Hugo installation guide.
Scroll down until you see a heading called Assets.
Click the appropriate build for your system to download it.
Installing the Executable
If you’re running Windows, you need to know how many bits the operating system is and what kind of processor you’re running.
If you’re unsure of these things, open the Start Menu and type About your PC and press Enter. The details will be available under the System type value.
Using those details you should download your corresponding version.
64-bit x64: hugo_<ver>_Windows-64bit.zip
64-bit ARM: hugo_<ver>_Windows-ARM64.zip
32-bit x86: hugo_<ver>_Windows-32bit.zip
32-bit ARM: hugo_<ver>_Windows-ARM.zip
For most people, the 64-bit x64 version will be appropriate.
Make a new folder called C:\Hugo\bin.
Move the downloaded .zip file into the newly created C:\Hugo\bin folder.
Then double click on the .zip file and extract its contents. The folder should
now contain the following 3 new files:
hugo.exe
LICENSE
README.md
From here, we’ll need to add Hugo to your Windows PATH settings. To do this:
Open the Start Menu and type “Environment variables”.
Select Edit the System environment variables.
Click the button that says Environment Variables….
Click to select the Path row under User variables.
Click Edit… under User variables.
Click Browse…, and select the C:\Hugo\bin folder.
Click OK on all following windows.
Using Package Managers
Alternatively, if you have Chocolately installed, you can run this command:
Close your Terminal. When you reopen your Terminal, Hugo will be ready to
use.
Using Package Managers
Alternatively, if you have Homebrew installed, you can also run the following:
brew install hugo
Or if you have have MacPorts installed, you can run the following:
port install hugo
If you’re on Linux/OpenBSD, it’s highly recommended you use a package manager install since Hugo does not require a new installation like in Windows and Mac.
Debian/Ubuntu
snap install hugo
Arch
sudo pacman -Syu hugo
Fedora/Red Hat/CentOS
sudo dnf install hugo
openSUSE Tumbleweed
sudo zypper install hugo
OpenBSD
doas pkg_add hugo
Install git
Download and install the corresponding Git for Windows setup for your system, either 32- or 64-bit.
From a terminal, run:
git --version
If it’s not installed, you’ll be prompted with an installer.
Debian, Ubuntu
sudo apt install git
Arch
sudo pacman -Syu git
Fedora, Red Hat, CentOS
sudo dnf install git
openSUSE Tumbleweed
sudo zypper install git
OpenBSD
doas pkg_add git
Recommended installations
While Hugo and Git are everything you need to get up and running, we recommend setting up an environment that will take care of content editing, managing Git changes, and running the Hugo commands all in one place.
If you already have a text editor of choice such as vim, emacs, or SublimeText, check out the Editor plugins for Hugo page. This will show how to integrate Hugo with your familiar environment.
If you don’t have a text editor of choice, we recommend installing Visual Studio Code. It comes built with the tools we need to work with Hugo and Git without having to resort to a command line.
Once you have Visual Studio Code installed, launch it and install the following plugins:
Saving any file will cause the page to be automatically updated in the browser.
Making changes
Editing existing pages
To edit an existing page, you can open a Markdown file in a text editor, make any textual changes you’d like, and save the file. If you are running a local server, you will be able to immediately see the changes as they will appear.
Adding pages to existing sections
If you want to add content, simply create a new markdown file in the content directory in the directory you want the content to live in.
Once created, each file needs a front matter (header), which can be either yaml, toml, or json specifying the following 3 things: title, menuTitle, weight.
The following shows an example of the front matter for a Glossary page:
The title represents what the page will be referred to as in the browser tab, as well as in link tooltips, and possibly in external cards that are displayed in tweets and in message previews.
The menuTitle represents what the page will be called in the navigation sidebar.
The weight determines the order in which pages in that same section level will be ordered. If we wanted a page to come before this in the tree, we would need to give it a weight smaller than 10, and if we wanted a page to come after this in the tree, we would need to give it a weight larger than 10.
After the front matter, the rest of the content in the page can be created in Markdown, as well as a handful of “shortcodes” that can be used to embed slightly more sophisticated elements easily.
Let’s look at the “Own POKT” section (found at https://docs.pokt.network). This is how the directory looks:
This should make sense, as the weights to buy.md, stake.md and wallets.md are 20, 30, and 10, respectively.
Adding new sections
Sections are defined by directories with an _index.md file in them. The site also has an _index.md file that serves as the home page in the root of content/. As mentioned above, sections are ordered by their weights relative to other pages in their section. Sections are ordered against each other by the weight listed in the corresponding _index.md.
To add a new section, create a new directory under content/ and add an _index.md file. You can also add any additional markdown files in that directory, as described above.
More Information
Pocket Network is an open-source multi-stakeholder community. Therefore, the best way to contact us is to join our community in Discourse and Discord.
Discord
You can join our Discord. We recommend doing this if you want to keep your finger on the pulse.
Be sure to start in the #👋welcome channel, where you can choose the topics you’re interested in.