POKT Economics Protocol Overview


POKT Economics Protocol Overview


POKT is a cryptographic utility token that is given as a reward to nodes for work done. Developers stake POKT to use the Pocket Network to relay data requests and responses to and from any blockchain.

  • All actors in the Pocket Network.
    • Decentralized Autonomous Organization (DAO)
      • The DAO consists of all nodes.
      • The responsibility of the DAO is to vote on active proposals.
    • Unfederated Nodes
      • Dispatch / Edge Nodes
        • Nodes that are responsible for creating sessions.
      • Service Nodes
        • Nodes that service the API requests of the application clients and relay the data through the Pocket Network are Service Nodes.
    • Federated / Validator Nodes
      • Nodes that verify the requests from the application clients and the data from the Service Nodes are Validator Nodes.
    • PoS Blockchain Consensus Nodes
      • All nodes can participate in the blockchain consensus. The more a node has staked the better chance that a node has to propose the next block.
    • Developer
      • An individual or group who is building a blockchain or decentralized digital database.

Units of time
  • The terms Pocket uses to define events that happen in the network.
    • Block
      • A block is a data structure that contains transactions; they occur approximately every 15 seconds.
    • Epoch
      • An Epoch is a summation of blocks occurring approximately every 15 minutes.
    • Era
      • An Era is a summation of all Epochs, occurring approximately every 24 hours.
    • Eon
      • Eons are a summation of Eras which occur approximately every 14 days.
Rewards & Incentives
  • Karma & POKT Mint. All rewards are given each Eon based on the nodes network join date.
    • Karma
      • Relay
        • X Karma will be generated each relay.
      • Block
        • X Karma will be generated each block.
    • POKT
      • Relay
        • X POKT will be minted each relay.
      • Block
        • X POKT will be minted each block.
  • Incentives POKT & Karma
    • Unfederated Nodes
      • Service Nodes
        • Receive 50% of Karma produced
        • Receives 6% of POKT minted
      • Edge / Dispatch Nodes
        • Receive 15% of Karma produced
        • Receives 1% of POKT minted
      • Federated Nodes
        • Receives 20% of Karma produced
        • Receives 83% of POKT minted
      • Developers
        • Receives 15% of Karma produced
      • PoS Blockchain Consensus Node
        • Receive X Karma per block produced
        • Receives X POKT per block produced
    Decentralized Autonomous Organization (DAO)
    • The DAO will receive 10% of all minted POKT each Eon, which will be allocated to proposals that have been approved. The remaining amount will contribute to the ‘safety’ in the DAO.
      • The safety shall not exceed X percent of the total amount staked in the network. Each Eon the protocol will check the balance, any amount over X percent will get burned.
    Staking & Unstaking
    • Staking
      • Developers
        • Developers stake X POKT which will allow them X relays.
        • Developers can stake additional POKT each Era which will allow them more relays.
      • Unfederated Nodes
        • Any node that is not a federated node will need to stake X POKT to join the network.
          • This stake allows them to service relays and to create a session as a dispatch node.
      • Federated Nodes
        • Once a service node has met the requirements needed to become a federated node, they can do so by staking an additional X POKT.
          • The requirements to become a federated node are:
            • Having (X) Karma
            • Being an active unfederated node in the network for 13 Eons
            • Staking an additional amount of POKT.
      • PoS Blockchain Consensus Nodes
        • The PoS blockchain consensus nodes will stake X POKT to be able to participate in the proof-of-stake consensus.
    • Unstaking
      • Bonding
        • Period of time for the staked tokens to mature.
          • Suggestion: 26 Eons (1 Eon = 7 days, total days = 182).
            • Subject to change through governance in the network.
        • After stake is deposited, it cannot be taken out before the end of the bonding period, once it has reached maturity.
        • In the case of unstaking during the bonding period a portion of the stake is burned while a portion is returned; however, there is a cap on how much can be unstaked which is directly proportional to how long the stake has been in the network.
          • Percent of days staked = caped percent to unstake
          • The inverse of the percent of days staked = percent burned
          • Total returned = percent unstaked - percent burned
        • When additional POKT is staked during a bonding period a new bonding period occurs.
          • If the new bonding period is > old bonding period
            • New bonding period = ((Days left in new bonding * percent of new stake) - Days left in old bonding) / ((number of times new stake has been added) + Days left in old bonding)
          • If the new bonding period is < old bonding period
            • New bonding period = ((Days left in new bonding * percent of old stake) - Days left in old bonding) / ((number of times new stake has been added) + Days left in old bonding)
      • Slow release
        • This mechanism starts the moment the user’s bonding period has completed.
        • Users are caped on what amount they can unstake by a certain percentage.
          • Suggestion: 60% once per Eon (7 days)
            • POKT unstaked = (Total staked * 60%)
            • Percentage subject to change through governance in the network.
        • A user can unstake once every Eon (once every 7 days).
        • If a user stakes more POKT after their bonding period has ended this triggers a new bonding period to start.
    Burning & Penalties
    • Penalties for Bad Acting
      • Minority session consensus
        • When all session validators do not come to a consensus, the minority of the group will be burned X POKT.
      • Failing liveness checks
        • When a node exits the network without submitting a transaction they get X POKT burned (larger than a network exit fee).
      • Propagating Incorrect Blocks
        • When a blockchain node proposes a block that is then rejected, the blockchain node will have X amount of their stake burned.
    • All fees for the network
      • Submitting a Proposal to the DAO
        • Anytime an actor in the network submits a proposal, the fee will be X POKT.
        • The fee will be based on the tier the proposal falls into, with a total of X tiers.
      • Staking & Unstaking
        • Nodes and developers will have X POKT burned each time they stake and unstake, see section V for unstaking.
      • Joining the Federation
        • Once a service node has met the requirements they can join the federation, this will burn X POKT.
      • Exiting the Federation
        • When a federated node leaves the federation they will have X POKT burned.
      • Exiting the network
        • When a node leaves the network they will have X POKT burned.
      • Challenge request
        • Any node submitting a challenge will need to pay a fee of X POKT.
      • Transfer POKT
        • Anytime a user in the network transfers POKT X amount will be burned from the transferers wallet.
      • Update Node Data
        • Each time a node sends a packet with their updated information the transaction fee will be X POKT.
      • Batch request
        • Batch requests are sent at the end of the session. The fee will be X POKT to be split between the participating validators in the session.

  • #2

    Some questions that veer off into governance instead of economics (may be better to create a new thread):

    • Do we want new service nodes to participate in the DAO?
    • Are we counting Developer deposits as a node in this definition?

    I’m not so sure we should think of Karma as a flat amount created per block or relay. Maybe it’s a miscommunication but this part seems to say that there will be a certain amount of Karma produced and it will be distributed accordingly.

    I’m thinking we should assign weighted values on each action that produces or reduces Karma, leading to a total per block because ultimately each relay successful result will be recorded.

    Clarify that developers stake X POKT for X relays

    Is this prorated based on how close they are to minimum bonding period?

    What purpose does the slow release serve?

    This may be an attack vector for malicious federated nodes. Need to model out carefully.


    Yes, I agree, this could be a new thread under governance.

    If I understand correctly, an example of actions would be, the dispatch node creating a session, a service node and 2 validator nodes doing work in that session, and a PoS node putting that session into a block. Each one of these actions would create X karma, the karma created for each action could be different.

    Yes, that is correct. I will edit the post to reflect this.



    Hi, I perused this doc, reread some parts, and came away with a sense that “it’s complicated”. All the node types, staking rules, etc. I’m not deeply technical but I’ve managed some software projects and I know that cases never get simpler. They only get more complex. But I didn’t comment because I don’t have the insight into the platform that @Tracie does.

    In a Zoom call I said as much to @Patrick727 and he said it’s simpler than it looks. I’d be curious to see what it looks like, meaning see a visual representation of the workings. Any chance you guys could diagram it?


    Well I said, it’d be simpler in a visualization. I am not as in the weeds as Tracie either.

    We have infographics planned for exactly this, but interested to hear from tracie the main differences from this economics compared to others.


    Hello, my next steps are to adjust the spreadsheet to reflect the current standards and from that I will be creating charts and graphs. I realize it may appear complicated but most of it is quite simple with some additional safety features to protect the network. Once I have some visuals created I am happy to share them here.


    Curious if these times are official or just arbitrary for now.

    So this makes it seem like the same amout of pocket and karma is generated each relay and block.

    Just thought I’d highlight this change for everyone.

    When all session ‘actors’, the SN is included in this.

    Just fix this spelling in the doc :wink:


    They are official, the spreadsheet is being created based on these standards.

    These numbers have not been defined. They could be the same or different.