PAUSED - Pocket V1 Economics and Governance R&D Support

Build Quick Grants
1

  1. This socket is to support the Pocket V1 Economics and Governance R&D being led by Block Science. Prior to Block Science onboarding, self-initiated work will focus on providing analysis on topics identified within PNF’s Economic Working Group for Pocket Network Protocol V1 document, as well as identifying potential topics not yet included in that document that may need coverage. Following Block Science onboarding, work will continue as above, but in close coordination with and under the guidance of Block Science. The Ambition being supported is “V1 is the most successful new protocol launch ever.”

  2. Type of Socket:

    • Initiative: $2K, paid and reviewed monthly, for the life of the initiative

  3. Commitment to “Default to open”.

I will work in the open and self-report monthly.

  • Work done will be done in the open and stored in the folder location provided below. Links to any work done outside this folder location (e.g., Discourse Research threads or Comments to V1 Utility Spec) will be provided in the Read Me file of this folder. Status will be continuously updated in the Status file of this folder.
  • In addition to this continuous form of updates, I will be self-reporting on a monthly basis on the progress made each month

  1. Link to where work will be stored
    Pocket v1 Economics and Governance R&D msa Support - Google Drive

  2. Wallet address for Socket payments
    0f6be6576293e3dc70654b08cc5167a7d40d3aff

2 Likes
2

Thanks msa, this Socket has now been opened

1 Like
3

To clarify for the wider community, PNF is talking to BlockScience, but we have not onboarded with them or even signed a contract yet. MSA has no affiliation with them either.

@msa6867 is welcome to read into the v1 requirements ahead of likely becoming a valuable contributor once research starts, but I have asked him to please hold off on trying to take ownership of any particular area, so we avoid any duplication of effort.

We (at PNF) are still working closely with the protocol team to align on which mechanisms are most likely to be best led by an outside third party expert with lots of resources but no context of Pocket (ie a party like BlockScience), which are the best fit for PNF / protocol to collaborate on, and which are the best fit for some of the other experts and contributors within our community.

In any case, no matter which contributor or group is the driver for the R&D regarding a particular mechanism or parameter, cross community collaboration and participation is paramount and the recommendations of any one contributor should never be final. Members from different research subgroups are expected to exchange ideas, discuss challenges, and explore potential solutions together and with the broader Pocket community.

Lastly, while we appreciate everyone’s interest in this crucial area for v1, please be patient with us as we finalise next steps in the coming couple of weeks. The planning stage has taken much longer than we expected, but this alignment phase is crucial and the clarity it should provide will mean we are in a better place once R&D starts.

7 Likes
4

Could more light be shed on economic sockets? I’ve asked PNF a few times in the past about economic sockets and there has never been any actionable response despite my expressed interest and significant participation in v1 architecture and token economics. What are the contribution opportunities for economic R&D?

While I appreciate the transparency PNF has after a decision is made, there has been little to no transparency prior to a decision being made, which makes announcements like these surprising.

Also could this specific socket be expounded upon? It’s not clear what the scope of work is exactly, and how it connects to past work that others have put into v1 economics that where never given an opportunity for compensation.

1 Like
5

REPORT FOR THE MONTH OF AUGUST 2023

V1 Mint and Burn - Methodology to Set Parameter Values: draft competed. This paper explores the various combinations of pegging burn and mint to either USD or POKT during maturity (~>10B relays per day). For each viable combination, the pros and cons of the combination is discussed, the primary feedback mechanism is explained, and a strategy to mitigate the cons is suggested. Various methodologies to combine multiple possible combinations into a hybrid policy are also catalogued. Two convenient summary tables capturing this information is found in the Conclusion section. Two follow-on tasks related to burn&mint for the month of September are (1) exploring the possible methodologies for setting burn and mint in the v1 “transition period” (roughly 1B to 10B relays per day) and (2) scoping burn & mint experiments that will be worthwhile to conduct in cadCAD once BlockScience has built out the Pocket model.

Differentiated pricing and compensation: This work was on the back burner for most of the month of August. Work will resume in September with an emphasis on (1) analysis of and implications of competitor pricing in CU and (2) use of geozone and chain-based pricing and rewards to incentivize right-sizing network coverage for each geozone and chain. For the time being, there will be little overlap between this exploration and C0d3r’s work on LLMs, though the topics will converge at some point.

Several pages of Notes were collected that contain seed thoughts for further exploration, some of which was later incorporated into the Burn&Mint and Differential Pricing papers referenced above Notes relating to the methodology for setting stake amounts will be expanded on in September to create a paper similar to the Burn&Mint” paper above which will catalogue the viable approaches to setting stake amount. This in turn can be used to scope experiments that will be worthwhile to conduct in cadCAD once BlockScience has built out the Pocket model.

2 Likes
6

Hi @msa6867

Thanks for sharing this update. I have some feedback when reviewing your work with the principles of 1) simplicity, 2) efficiency and 3) impact in mind.

Can you please explain more about how you think your work will align with the other work already going on?

We are already paying Blockscience to do the modelling and simulation work to help us decide on the parameters for mint and burn, and we are building on the work that @RawthiL and his team have done on the MINT mechanism to determine how all of these different parameters work together, so from what I have read so far I do not think that the DAO can justify paying you for this work, at least on an ongoing basis mainly because your work will most likely either be duplicative or distracting to the work that is already going on.

Re differentiated pricing and compensation, my understanding is that @RawthiL and @bulutcambazi (C0d3r) are already working on / planning to work on this, so please do not commence any new research on this area without their input first, as otherwise, it will be a poor use of the DAO’s funds. It could also cause delays and/or confusion to their R&D workstreams.

Consequently, I recommend that this Socket goes on hold until you can demonstrate how your work will positively contribute towards our broader v1 Economic R&D goals in a more aligned manner.

While it is great that you are willing to put your time into thinking about all of this, and I have no doubt that your input will be valuable once some of the other contributors’ research is ready to be shared for feedback, we need to be super mindful of what impact we expect to receive from the work that the DAO is paying for. And I haven’t seen enough evidence from what you have shared to date about the impact that the DAO is receiving for these payments.

1 Like
7

Thanks for the update, it’s a rather interesting overview (specifically the summaries of the mint and burn). However I agree with @Dermot , in that the work needs to be aligned with the economics R&D post.
It seems that you are covering many topics that are divided among many contributors and that could cause some confusion. Aligning your work to an specific area of the shared spreadsheet will be the most effective way to work.

Just to clarify, we are not working on differentiated pricing, that’s C0d3r’s work only. We are interested in LM RPCs, which is a big subject by itself. We will communicate about his in due time, I would not like to mix that subject with this thread.

2 Likes
8

Thanks @Dermot . Re differentiated pricing, I will get with COd3r to make sure I understand their research; I am pretty confident that my pursuits in this regard are orthogonal to what they are working on.

Re Blockscience, I will dm you to make sure I understand the scope of Blockscience contract wit PNF before addressing this further.

2 Likes
9

@Dermot

Re differentiated pricing: I have been interacting with COd3r on their v0 proposal for RTTM. I see no duplication of effort or working to cross purposes between my proposed work in this regard and theirs. As node runners, they are focused on per-chain rewards and the v0 code change needed to accomplish this. On the other hand, I am focused on v1 and approach a broader subject from a systems engineering perspective. My research will deal with

  • how enabling per-chain, per-geozone and per-call differentiation can be accomplished at the same typle most efficiently (eg coding per-chain now only to have to code per-geozone later is highly inefficient)
  • working out the implications on per-x rewards on per-x burn for self-staked apps and gateways
  • working out the implications of per-x rewards for gateway sales process
  • working out the implications of per-x rewards both on inflation, and the ability to predict inflation (both in maturity where mint<burn and in the subsidized transition period)
    working out the implications of per-x rewards amongst network providers where reward rates may no longer be as predictable as prior to per-x rewards
  • Re per-call-type pricing, whether or not the pricing model of competitors necessitates POKT moving in this direction.

I think this work aligns with the work COd3r is doing, because (1) it is more efficient to code once to achieve the final desired state rather than twice in steps and (2) it works out all the systems engineering issues that are being raised in the comments section to their pre-proposal but for which it is not really their area of expertise to address.

With your permission, I would like to resume this socket to start focusing on these issues, which will probably take a few weeks to a month, even if the socket as an ongoing concern following that is TBD.

Re staking (both on demand and supply side) - and possibly other “economic” parameters such as burning - , before addressing the larger picture of items that overlap with blockscience and other community participant, there are some experimental thoughts I would like to pursue that is completely outside the purview of others having to do with potential opportunities for applying concepts of “grandfathering” to the tokenomics - both at the transition from v0 to v1 and during the transition from v1 to maturity. This, e.g., might be useful as a tool to close clients in the sales funnel (eg "exisiting clients only have to stake x amount or will have x burn rate if they get in before the transition to v1, but will jump to y once the transition happens). For example, an effective way this might have been used in v0, but wasn’t because there was no mechanism to allow it, was to jack up the amount of POKT required to stake a new node at the end of 2021/beginning of 2022 to slow the influx of new nodes while grandfathering existing nodes who got in earlier. Looking into this area would probably be only a couple weeks before interacting with PNF to see if anything is worth pursuing further, as any such capability does come at the expense of code complexity to enable it.

Re dynamic pricing of applications, I know you listed “C0d3r and Ramiro to discuss in the first instance” but unless they have have laready accomplished this task, I would like put together pseudocode for this task; I believe it will be fairly straightforward. and should only take a week or two

Re interaction with BlockScience, there are two possible paths that can be taken.

  1. Blockscience is the sole determiner of what experiments to run and based on those experiments makes recomendations as to parameter values/ranges. If pertinent experiments that the community feels need to be done were not included then either BlockScience or the community would need to go back and run the pertinent experiments, which may completely up-end the recommended values/ranges, leading to delay, confusion etc.
  2. The DAO/PNF makes a list of experiments that it feels must be done in order to make judicious choice of parameter values/ranges/ methodologies (for dynamic-value parameters), and better yet has for each experiment a hypothesis on what they expect the experiment to show. Out of this complete set, BlockScience then makes their recommendations.

To me, the second approach is more efficient, and leads to less confusion and delays than the first. This is where I was heading toward as indicated in the future-work discussion within the monthly report. Please advise.

1 Like
10

Given that it is hard to point to the impact of the work done to date, I would be much more comfortable if we reduce this Socket to $1k / month for now. And we can review again at the end of the next month. Does that work for you? (Btw, Anyone in the DAO is able to support/challenge any Socket)

As this proposed research falls outside of the research scope that the protocol and PNF have agreed and shared with the community, it’s not something that the DAO should pay for, at least not upfront. However, you are welcome to pursue this research and apply for a retroactive grant if your research results in an impactful result for the DAO.

(As an aside, my immediate thinking is that the type of mechanism you are proposing wouldn’t be credibly neutral and isn’t practical in any case as there is no client of any gateway that currently stakes any POKT directly. They are all paying with credit cards based on their usage or the monthly payments agreed in their contracts with PNI, and soon Nodies, et al).

This could be great! Please contact both of them and ensure they align with your approach before proceeding to carry out any significant work.

We are in constant discussion with BlockScience about the goals and KPIs for their research. We will make an update to the DAO next week in this regard.

BlockScience’s work is focused on answering the research questions we have set for them in the spreadsheet shared with the community. They are the world’s experts in this type of work, so it makes sense for them to be the driver. We are working with them to open up this work to share it with the community for feedback in due course. Consequently, you will have the opportunity to provide your input along with the rest of the community in the coming months. And the DAO will be the ultimate arbiter of what are the right parameters for each mechanism in question. However, the DAO should not fund your independent work in the same area, as it could lead to duplication of effort and/or confusion about who is the driver of the project. I hope you understand.

2 Likes
11

Yes that is amenable

Will do

I will use that thread then as a place to suggest goals/KPIs if I see something that may be missing

2 Likes
12

@Dermot,

After giving this further thought, I think it will be best to close this socket. Once BlockScience releases their model and makes their recommendations, we can revisit opening a socket. While working out the details of v1 differentiated pricing is important, it may not be needed at the moment and would more efficiently be worked on during that later period.

If PIP-31 passes and cod3r posts a PUP for non-default values, the following line item will need to be worked out for their specific use case. This can be done as part of the debate of such a PUP and lessons learned from that limited v0 endeavor can help inform the broader v1 picture.

The only thing that I recommend be done sooner than later is for the dev team to give a bit of thought of how per-call-type price differentiation can be implemented in the future if the need arises. While such a offering would likely be post launch, architecutral decisions made now could make it either straight forward or very complex to implement through code changes in the future. (I do not see any such issue arising with per-chain or per-geozone differentiation as the hooks are already their to make such distinctions).

Please let me know if you are in agreement to move the status of this socket directly from paused to closed.

3 Likes
13

Agreed and thanks for working in the open like this @msa6867

Let’s revisit everything again in a few weeks

2 Likes