PNI Update to the DAO (April 21, 2023)

PNI Update (April 2023)

Arthur Sabintsev, COO & Kevin Jenkins, Capital Markets Lead at Pocket Network Inc.

Hello, friends! In this update, we will offer a transparent overview of the state of Pocket Network Inc. (PNI) as of the end of 1Q23. This is the second edition of this type of update, which builds upon and consolidates the updates that we provided at the beginning of last quarter:

Finance Overview

  • New Enterprise Customers Signed in Q1: 9
  • Closed Contract Value in Q1: $830,000
    • This is combined from both our New Chains and Partnerships business lines.
    • This excludes any self-service revenue accrued through the Portal, and any other sources of revenue.
  • Paid Daily Relays from Q1 Signed Contracts: 535,000,000 Relays
    • The aforementioned 9 net-new enterprise customers have, in aggregate, paid for a throughput of 535M daily relays, but they do not yet actually send that full amount of relays through our network.
    • Currently, displaying a breakdown of this information is challenging due to certain customers being subject to a use-it-or-lose-it policy (where monthly recurring payments limit the maximum amount of relay throughput) and some customers are on a Pay-As-You-Go (PAYG) plan.
    • With the forthcoming introduction of our Data Warehouse (which will be discussed below), we will be able to offer more detailed insights in a future quarterly update, allowing us to distinguish between paid daily throughput and actual daily throughput.
  • Monthly Operational Expenditures: $600,000
    • This is the total monthly cost of labor and services at the end of Q1 (e.g., what it costs to keep the lights on)
    • This is a 50% reduction in monthly spend (down from $1,200,000) at the end of 2022 (discussed in the OKR sections below).
    • This number excludes any revenue we’ve generated
  • Cash on Hand: $4,000,000
    • This excludes any value from the 87,000,000 POKT owned by PNI or allocated to its employees vesting schedules.

PNI POKT Buyback

This report showcases the segment of PNI RPC revenue that has been designated by PNI for the acquisition of POKT. As PNI presently utilizes Gigastakes during the v0 phase, we’ve chosen to allocate part of the RPC revenue to strengthen our POKT treasury, preparing for a post-v1 era where customer throughput staking will be necessary. Moreover, this approach aids in our readiness for token burning (e.g., Application Burning Rate [ABR]) once approved by the DAO.

Note: In the future, following the DAO’s implementation of ABR, demand-side fees used for purchasing and app-staking POKT will be burned at a yet-to-be-defined rate as requests are handled. To maintain network throughput, users must replenish their stakes as needed. These burned app stakes will add to the protocol revenue, which will be fully on-chain post-v1. For more information on app economics, please refer to the documentation.

We’ll keep it brief and simple with this report:

  • Sources and dollar amounts of RPC revenue allocated to acquire POKT
    • dApp RPC (B2B)
    • Gateway-as-a-Service RPC (B2B2C)
    • Portal Platform RPC (B2C)
  • Some key highlights and a quick look at the pipeline

This report excludes additional revenue sources from PNI, which include but are not limited to:

  • New chain integration fees
  • Value-Add services (e.g., MEV, indexing, storage, etc.)
  • Node running rewards

This information only includes data for 1Q23. The prior update (referenced above) was for the latter two quarters of 2022. Therefore, this report is not comparable Quarter-over-Quarter (QoQ), but will be comparable QoQ going forward.

In 1Q23, we shifted all enterprise agreements to a Software-as-a-Service (SaaS) model, typically spanning 12 months and without any POKT obligations (e.g., customers pay a monthly subscription fee for RPC service). This impacts the 1Q23 RPC revenue designated for POKT acquisition, as previous reports showed total contract value (e.g., one-time payment) versus recurring monthly payments.

In the short term, the results will appear smaller, but they’ll be compounding monthly assuming no churn due to the exceptional infrastructure provided by the node runners in the ecosystem. Additionally, in 2022 we allowed for a couple enterprise customers to purchase and stake POKT themselves which represented 60% of the numbers shared in 2H22.

In 1Q23, PNI decided to allocate 60% of paid RPC revenue to acquire POKT. This is subject to change over time, given fluctuations in market conditions, v1 protocol parameters, and other influencing factors.

Product Offering Q1 2023 RPC Revenue Allocated To POKT
dApp RPC (B2B) $82,000
Gateway as a Service RPC (B2B2C) $18,000
Portal Platform RPC (B2C) $4,000
TOTAL $104,000

POKT will be purchased in the open market via VWAP on a routine cadence as collections are accrued.

Key Highlights and Notes

Below are some of the noteworthy points of context to go along with the report. We can’t share all the detailed information, given NDAs, but this should help provide some insight.

  • dApp RPC Sales (B2B)
    • Given the explosive growth in new networks launching, we focused heavily on this segment of the market with 9 new chain launches this quarter. This includes mainnets and testnets across Arbitrum, Optimism, Celo, Velas, Oasys, Kava, and Polygon zkEVM. We expect this trend to continue, as we have another ~20 networks in the negotiation / proposal stage of the pipeline. Meanwhile, our primary focus on the dApp RPC side remains supporting wallets, GameFi, and DeFi in expediting their multichain strategies while minimizing costs.
  • Gateway-as-a-Service (B2B2C)
    • New partnerships with GetBlock and OnFinality have validated this model, aiding us in gaining momentum with several prominent RPC providers we anticipate partnering with in Q2.
  • Portal platform (B2C)
    • The Portal has proven to be an effective solution for self-service monetization, enabling prospects to swiftly evaluate the infrastructure. Additionally, it allows the sales team to identify potential enterprise leads as their usage increases.

Note: with the exception of Portal PAYG revenue, you can follow the Marketplace team pipeline here.

Our distinct value proposition in the market has helped us capture market share with new networks and convert centralized RPC providers into customers (e.g., distribution partners). We anticipate Q2 sales to nearly double, given the healthy progression of deals in the pipeline and the recurring nature of 2023 SaaS agreements.

How you can help accelerate demand-side growth

We are actively concentrating on expanding our market share by capitalizing on our competitive strengths, so any warm introductions are highly valued. This could involve new blockchain networks for Pocket integration, dApps requiring RPC service across supported networks, or existing RPC providers seeking to offer more networks to clients while optimizing infrastructure expenses. Community engagement on social media, Discord servers, and Telegram groups also helps promote decentralized RPC as reliable, performant, secure, and cost-effective at scale. You can contribute to network demand by raising awareness in communities you’re active in, such as blockchain networks, gaming, wallets, or other dApps.

Here are a few shareable links you can utilize today:

Moreover, we’ve been enlisting referral partners to boost sales and market penetration. If you have strong connections throughout the ecosystem and are interested in supporting our sales growth, please contact our CFO, Laxman, at to discuss the commercial aspects. Generally, we base agreements on a percentage of the total contract value, but we remain flexible for the right partners. Feel free to reach out to anyone on the Business Development team or contact Dicky about specific deals: or Telegram: Contact @DickyG6 on Telegram.

Team Composition

In our last update on January 25, 2023, we discussed the company’s two rounds of layoffs, reducing our team from just over 70 people to 44 members. Since then, an additional 5 individuals have departed the company of their own free will, but in that time we have also welcomed 4 new individuals: 2 sales team members, an accountant, and our new Head of Marketing, Daniel Crowe.

Below is the current composition of the company:

  • Corporate Leadership: 4
  • Finance & HR: 4
  • Marketing: 4
  • Product Engineering: 20
  • Protocol Engineering: 6
  • Sales: 5

After restructuring the team, we’ve organized the divisions within the company as follows:

  • Design, Engineering, Marketing, Product, and Protocol roll up to Arthur (COO)
  • Finance, Accounting, HR, and Sales roll up to Laxman (CFO)

In both this update and our previous one from January, we have meticulously detailed the structure of our team to reassure our community that, even after the recent layoffs, we have retained an optimal workforce throughout the organization. This team will continue to develop and deliver products that effectively drive demand for the protocol. As we move forward, our hiring focus will primarily center on Sales and Protocol. As the business expands, we will build a formal Customer Support function. Occasionally, we may also bring on exceptional engineering talent to address the evolving needs of our growing enterprise. All present and upcoming job opportunities can be discovered on our careers site.

This will be the last time we explicitly delve into the team’s composition, as we’ve now comfortably settled into an organizational structure we believe is appropriate for reaching our goals. As you read further, you’ll see how our team is set to make things happen.


Entering 2023, we found ourselves in complete survival mode. Consequently, our objectives revolved around steering the organization back on course, despite reduced staffing, by concentrating on lowering costs and boosting sales. The Objectives and Key Results (OKRs) presented below are a version tailored for the community, based on the ones we employed internally.

Please be advised that the following were compiled towards the end of January subsequent to a reduction in team size. Our team had aimed to exceed expectations and reach our goals to the best of our abilities. However, as with all ambitious objectives, some were achieved beyond expectations, while others were only partially completed.

O1: Getting to Sustainable Infrastructure

  • KR1: Consolidate on 1 Cloud Provider
    • In 2021, the Protocol team was operating as a separate and isolated entity within PNI. They made the decision to use GCP for their infrastructure while the rest of PNI used AWS.
    • In early 2023, we signed an extremely favorable enterprise agreement with GCP, which included a steep discount in services on a 1-year term, co-marketing endeavors, sponsorships, and professional service credits.
    • This deal is what led us to begin migrating our rewritten Portal to GCP, which is scheduled to go live over a 2 weeks period starting on April 24 and culminating around May 8, 2023.
  • KR2: Offload 100% of the Altruist Network to the Community
    • We successfully offloaded 100% of the Altruists to the community, much of which is now being reimbursed by the DAO, since many of the altruists are working with the Community Chains project maintained by Decentralized Authority.
    • This allowed us to transition the financial responsibility for maintaining the backup infrastructure from PNI to the DAO, resulting in savings exceeding $100,000/mo for PNI.
    • The entire exercise prompted the Protocol team to address a persistent issue concerning session-rollovers, which initially necessitated the creation of the altruist network. Their anticipated fix is set to be introduced in v0.10.0 of the Protocol, and is scheduled for release later this quarter.
  • KR3: Goal: 30% Reduction in Infrastructure Spend
    • In reality, we reached a 47% reduction in infrastructure spend by doing the following:
      • Assessing all our product usage on AWS and terminating unused and underused provisioned services
      • Offloading all but 30 nodes to the community. At the time of publication of this document we run 1,450 nodes with 6 node runners in the community.
    • Massive kudos goes to Fred and the Infrastructure team in getting us here and salvaging our runway in Q1.

O2: Generate $1m in Total Contract Value and Begin New Product Marketing Engine

O3: Product Improvements and Releases ahead of the Portal v2 Launch

  • KR1: Release Team Access Management
    • We launched this new functionality in the Portal toward the end of Q1, allowing multiple users from a specific organization to enjoy customized access to various features within the portal, such as billing, creating endpoints, allowlisting, and more.
  • KR2: Two Net-New Feature Designs Completed
    • We have finished designing a new Pricing page that is set to go live this quarter.
    • The design for the revamped Requests page, displaying user requests and errors, is also complete. We are planning to implement the redesign of this page closer to the end of this quarter.
    • Enhancements to the Endpoint card in the Portal app (for logged-in users) have been completed and are scheduled to roll out later this quarter.
  • KR3: Add at least 5 new features ahead of the Portal v2 Launch
    • Quality of Service Module
      • Isolate and define logic around monitoring and selecting the best nodes to support each user’s specific call
    • Chains Module
      • Isolate and expand upon our capabilities to provide unique logic and structure for each chain we support
    • Metrics Module
      • Isolate and enable a single source of truth to our logging and metrics
    • Dispatcher Module
      • Isolate and improve logic around connecting to and caching results from our dispatcher and the propagation of sessions with the goal of faster switching to new sessions when they become available
    • Plugins Modules
      • Isolate and extend the ability to add new business logic in the future
    • Middleware Module
      • Isolate and orchestrate the logic needed to execute the portal api
  • KR’s 4-7 were incomplete
    • Quantify demand of an Indexing-product offering
      • We have partnered with Covalent to launch their product as a value-add feature within our feature. Instead of rushing to release this product last month, we will be launching it mid-quarter, and will be marketing it, and monitoring the uptake of this feature within the first half of this quarter.
    • Release v0 of the Data Warehouse
      • As part of our GCP deal, we received a very generous budget for contracted professional services work, which we began utilizing at the beginning of this quarter to contract multiple GCP-certified data engineers to build out an MVP of this product.
      • We expect to have a working version before the end of May and are currently hiring one individual to join the team to continue iterating on the product after the professional services contract ends.
    • Redesign the Metrics Page
      • As we are building a new Data Warehouse this quarter, we decided to punt on delivering a new metrics page until we assess what data we have available to us once this product is live and gathering data in production.
    • Retire Influx DB
      • We are looking to consolidate all of our database architecture onto fewer Relational Databases (RDBMS) for the time being and work our way up to something more sophisticated. Currently, Influx, which is a time-series database, is used for the Relay Meter, and is out of pattern with the remainder of our architecture.
      • We cannot retire this database until we finish our migration to GCP and release the Data Warehouse.

O4: Accommodate Protocol Demand Growth and Consistently Deliver V1

  • KR1: Double the Growth Budget of the Protocol to 6 billion relays/day
    • As mentioned in the v0.10.0 Release Guide, PRs were merged in that will be released later this quarter to achieve this goal.
  • KR2: Complete 50% (in aggregate) of M1, M2, and M3 Milestones
  • KR3: Engage 3 External Project Contributors
    • This quarter had many new contributors, but there were four that proactively contributed multiple improvements to v0 and v1: H5law, 0xBigBoss, Prajjawalk, msmania
  • KR4: Produce 2 End-to-End Demos for the Community


Given the success of the previous quarter’s OKRs, we decided to double down on our strategy as defined in our aforementioned January update. You’ll notice a clear shift into centralizing all of our focus on Portal development and shifting all resources on working towards driving demand into the Portal.

O1 (Sales): Generate Revenue for PNI

  • KR1: Secure $1.5m in Total Contract Value
    • $1m from New Chain Launches
    • $250k from Partnership (RPC) Sales
    • $250k from Referral Partners
  • KR2: Onboard 10 New Referral Partners
    • Our marketing team has created promotional materials to assist our investors in reaching out to their portfolio companies (portcos) and individuals in connecting with their networks.
    • We are providing generous incentives to encourage them to refer new clients to us, and we have established a goal in the first key result to ensure that approximately 17% of the revenue generated in Q2 is from this source.
    • Notable net-new referral partners include:
  • KR3: Establish a Foothold in High Value Sectors
    • Sign at least 1 DeFi app
      • This plays into our MEV strategy and multichain advantage to help them expand their business quickly across networks
    • Sign at least 3 wallets
      • This plays into our MEV strategy and multichain advantage to help them expand their business quickly across networks
    • Sign at least 3 gaming apps
      • This will generate the most amount of revenue for the protocol, as games generate high volumes of RPC requests on a daily basis.

O2 (Product): Enable Portal as a Platform

  • KR1: Launch Portal v2 in Production
    • This is scheduled to happen over 2 weeks starting on April 24
  • KR2: Enable MEV Revenue Share (MEV-Share) on Private Endpoints
    • This feature includes changes to the MEV plug-in to enable MEV protection (backrunning) on private endpoints. The MVP will be available for enterprise customers and will be set by internal Portal admins. The next iteration will allow paying users of different plan types to opt-in on the Portal UI. Scheduling for the second iteration is contingent on the success of the MVP.
  • KR3: Improve the Developer Experience in the Portal
    • Refresh the Company Website
      • Create an ungated pricing page that describes the pricing options for the developer
      • Create a docs page for developers to learn about our products or troubleshoot issues
    • Redesign the Portal application to be more user friendly and more aligned to what our users are expecting
    • Redesign our New Chain strategy to be more automated
  • KR4: Reduce Gamification of Traffic
    • Redesign public endpoint strategy for existing and new public endpoints by introducing throughput limits on public endpoints and our free tier for Private RPC endpoints
    • Reduce Always Free daily limit from 250k to 100k relays
    • Improve our process for handling delinquent subscriptions

O3 (Product): Exceed Centralized Quality of Service on the Decentralized Network

  • KR1: Node Classification
    • Improve assessment of node performance to better inform the node selection process in the Portal
  • KR2: Gas Limit Enforcement
    • Ensuring users who need particular gas limits are matched with nodes that support higher limits
  • KR3: Dynamic Allowance
    • Both Portal customers and PNI should be able to dynamically set block/sync allowance per chain with data and a dashboard to inform them of their decision making.
  • KR4: Documenting Supported Chains and Methods
    • Enforcing node selection priority of nodes that do not adhere correctly to the methods we say we support
  • KR5: Net API Enforcement
    • Matching users that need this particular API to nodes that are known to use this API

O4 (Marketing): Establish a Predictable Marketing Engine for Demand and Community Growth

  • KR1: Drive 5 sales conversations per month from marketing generated leads
  • KR2: Generate at least 1 piece of collateral for each stage of the marketing and sales funnels by sector:
    • Gaming
    • New Chains
    • Wallets
  • KR3: Drive 500 new users to the self-serve portal, of which at least 30, are new paying users
  • KR4: Welcome at least 1,000 new members into the Portal platform Discord server
    • PNI is opening up their company Discord to the public to begin cultivating a developer (demand) ecosystem
  • KR5: Set Business as Usual (BAU) health metrics and their benchmarks:
    • Monthly Average Users
    • Monthly Recurring Revenue (self-serve Portal users)
    • Monthly Average Sales Qualified Leads
    • Monthly Average Community Growth

O5 (Protocol): Develop a Robust Scaling Solution for v0 and Prepare for v1 Testnet

  • KR1: Prevent chain halts and increase V0 growth budget
    • Release 0.10.0
    • Increase block size to increase relay budget by at least 500-1B daily relays
  • KR2: Prepare V1 for Testnet
    • 80% completion M1, M2 and M3 milestones
    • Send height query relays to an ETH data node
    • Implement the first Fisherman Proof of Concept
    • Develop a detailed testnet Go-to-Market plan

Other Notable Updates

  • Ledger Status Update
    • As of mid-April, we had our Audit completed by Quarks Lab.
    • Ledger has accepted those changes and has promised to launch our Ledger app in Dev Mode in Ledger Live ASAP, with a full release following shortly thereafter.
    • We are cautiously optimistic that we’ll be live in Ledger Live in Dev Mode sometime in May 2023, with a Full release shortly thereafter. We reiterate here that this is completely out of our hands at this point in time.
  • New Discord Server for PNI
    • We have begun soft-opening up our Discord to the wider community in an effort to build a demand-centric ecosystem focused on PNI’s Portal. If you’ve gotten this far in the article, we invite you to join here: Portal
    • Official announcement will be made during the Weekly Community Call on April 27th, 2023
  • Developer Focused Events
    • PNI launches developer meetup groups. Events will initially be virtual meetups attempting to onboard web2/web3 developers into the ecosystem. We will be hosting our first virtual meetup on May 11. Please note that these events will also be streamed to our PNI’s Discord server as well as a Twitter Space


As promised in our first update of the year, we’re doing whatever it takes to make this project a resounding success, and we’re proud to say that we’re trending in the right direction! We hope the transparency we provided in this update as it relates to our finances, business approach, and protocol development has shown that we have a sound strategy. We’re incredibly grateful for your support and passion for the PNI project. It inspires us every day to work harder and deliver better results. As always, we remain dedicated to our goal, and we’ll continue to keep you updated every step of the way.

Thank you!

Arthur, Kevin, and the PNI Team


Thank you Arthur, Kevin, et al for putting this together.

Here are my take-aways so far. I had been expecting monthly realized revenue to come in at around $60k and actuals are very close to this ($57.8k = $104k / 0.6 / 3months). I think this bodes well for the project. This compares to about $10k/mo revenue in H2 of 2022 (approx $60k to 70k over 6 months after subtracting off the 2 large self-stake clients who own their own POKT). Thus a 6-fold increase in revenue between H2 2022 and this quarter. Next quarter, I assume we can expect the same level of monthly revenue accrued from existing contracts… PLUS revenue from contracts to be closed in Q2. Tis is the cumulative effect at work.

I had been expecting average contract price per relay to be of order 0.000001 to 0.000002 (ie heavily subsidized) but reading between the lines, actuals seem to be 0.0000043 (assuming the $830k contract value to be for 1-year contracts then $830k / 535M relays / 365 days). This is very good news, if true, and means that PNI is able to close deals at market rate which bodes well for turning on app burn in the future. If the assumptions made above are off (namely, if the contracts are multi-year contracts rather than 1-year contracts), please advise, so tat te DAO can estimate avg price per relay being collected. Note that the realized revenue per relay is even better than this because of the use-it-or-lose-it nature of contracts. If they averaged 50% utilization of their allotment, then the revenue per relay may be closer to 0.000008. In future reports, it will be good to note average utilization of the contract allotments, if you are able to collect that data.

You say that " POKT will be purchased in the open market via VWAP on a routine cadence as collections are accrued." The future tense implies that purchase of POKT with the $104k has not taken place yet. This is disappointing. Perhaps the number may seem small compared to CEX daily volume, but the buy pressure could not have hurt in the last couple months. I appreciate the commitment to purchasing “on a routine cadence”. I suggest at least monthly, or even better spread out over the month, with monthly breakdown of POKT purchases shown in your quarterly reports. Even better if you could give end-of-month summaries to the DAO of how much POKT was purchased the previous month. (As a NIT, please note that it is the reporting of the purchases that are VWAP, not the purchases themselves.)

Last, the delta between the Complete 50% (in aggregate) of M1, M2, and M3 Milestones KR and the 30% actual is concerning, considering that the push to v1 is on everyone’s minds. Separate guidance on implications on v1 testnet and mainnet timelines, as well as guidance on root-cause and corrective actions would be appreciated.

All in all, good job, team!


Thanks for the follow up.

  • For the breakdown of paid RPC usage, we should have it in the next update, or in the update after that at the very latest.
  • Regarding the purchase process around POKT, I leave this to @kjenkins and/or Laxman to answer.
  • Regarding the v1 timeline, I think you’re better suited getting an answer from @jdaugherty or @Olshansky.
1 Like

Thanks. Projecting into Q2, if we hit the Q2 OKRs, we should be expecting ~$170k/mo revenue / $100k/mo POKT purchases; at least by end of Q2, if not averaged over Q2


Realized revenue would be 173k*

Must have been a typo because your math works out there.

1 Like


Problem: Team is changing, new initiatives (across both v0 & v1) were started, hitting unknown unknowns during development and “keeping the lights on work” to support the rest of the organization.

SolutIon: Keep growing and picking up momentum as a team, update the timelines to reflect our new capacity, scale our learnings through documentation and automation, and leverage the rest of the engineering org as we head into M3 development.

Team Composition

The team is currently composed of 4 FTE Protocol Engineers, Jess and myself. Two of those engineers started only in Q1 of 2023 but are already delivering very impactful work. We also lost our most tenured and most senior Principal Protocol Engineer, which had an impact on our timelines.

We are working closely with our external contributors but are also actively looking for a replacement, putting a lot of emphasis on finding the right candidate in terms of culture, experience and expertise rather than rushing to grow the team.

In addition, we are leveraging tools like ChatGPT to automate our work and make each individual more efficient. If everyone on a 5 person team becomes 20% more efficient, that goes much further than hiring someone new.

Using this opportunity to ask for anyone reading this to share this job posting with your network and help us find great candidates who are excited about the project.

New Initiatives


In V0, you can see that the 0.10 release guide contains a lot more than just a block size increase (new features, bugs, etc…). The core protocol team has zero fulltime v0 resources and are heavily grateful for the help of the community, supporting everything from architecture, design, testing, implementation, TestNet maintenance, etc…

This also does not capture the Probabilistic Proofs design (completed in Q1) which we put together with the PoktSCAN team as a backup plan in case V0 finds itself in the situation of needing to scale 10x.


We did not originally plan to support IBC until after V1 launch, but this effort was started and being spearheaded by @h5law. Though it did take some time away from our primary focus initially, it is already beginning on have positive impact on only on future interoperability, but also M1-M3 design decisions.


On the protocol side, a lot of our time behind the scenes is also spent supporting PNF on reviewing various proposals ranging from tokenomics to interoperability. This involves both research and conversations with other projects and protocols, some of which are still fruitful followups from ETH Denver.

A lot of it is too premature to share, but just one (of many) example of a question we discuss: Should we, and what would it take, to integrate with Axelar to give Pocket EVM interoperability?

Using this opportunity to shamelessly ask for anyone reading this to share my presentation from ETH Denver to get more eyes and interest on Pocket within the crypto industry.

Unknown Unknowns

V1 Bugs

Though we did account for bugs an issues in our V1 Development plans, some things turned out to be more difficult than originally anticipated.

For example, we demoed the first version of Consensus State Sync last week, but kept giving updates every Devlog on issues we were encountering.

As another example, V1 infrastructure was impacted by the migration managed by the infrastructure team. This was expected, but still took longer than expected.

Lights on Work

Across backend, marketing, and PNF driven initiatives @jdaugherty and myself find ourselves needing to provide a lot of support and answer questions from the Protocol’s perspective. I don’t think this requires more detail but important to note.


It would be an unnecessary overhead for the protocol team to publicly share its standups and notes to internal meetings, but we do try to be as public as possible:

The details to the true source of where/how our time is spent is spread across the resources above, but hopefully this summary also paintained a picture of what we’re doing.

@msa6867 Let me know if there are any more details I can provide.


@Olshansky - wow, this definitely goes over and above! Thank you for taking the time to put this response together


Thanks for the comment and observation. In the spirit of transparency, you’re correct that this purchase has not been completed yet. The primary rationale for this is that these purchases are based on the collected RPC payments and a lot has come in this past month. Most of this is due to the timing of deals closing and the respective collections. Given we’ve transitioned to a SaaS model, we’ll be planning to do this VWAP on a much more frequent cadence (e.g. likely monthly). I wouldn’t be opposed to being transparent about POKT purchased post-VWAP completion, but can you help me better understand the rationale behind getting this info monthly vs. in the quarterly report going forward?

1 Like

(1) The current emissions policy is to calculate a trailing average of daily relays and adjust emissions accordingly. The policy does not distinguish between free and paid demand. Neither does the policy in the recent RDI proposal.

An alternate policy as we move into more paid demand may be to make distinction between free demand and paid demand. For example, reduce emission subsidies much more aggressively for free relays while adding back in an allowance to counterbalance POKT purchased from demand. Eg., instead of inflation = 12% and dropping , move to inflation = 5% and dropping (to subsidize node runners for handling free relays) + mint in balance with demand-side POKT purchased). This would be accomplished by obtaining monthly report of POKT purchased and feeding that info into the setting of emissions in the following month.

(2) The DAO, over the next few quarters, will be working to develop models and policies in preparation of v1. Being able to do trend analysis is important to this process. Until app burn or some off-chain equivalent turns on, monthly realized revenue that is “protocol related” and/or POKT purchased by PNI from this revenue (assuming a regular cadence) is very helpful. Granularity of monthly vs quarterly is needed and reporting monthly vs having to wait eg until July to start this process is helpful.