UPDATE 6/1/23: Budget has been reduced to $13k USD equivalent of POKT, down from the original ask of $23k and down from the approximate $19k reimbursement that would have resulted in implementing a cap against the original $23k ask.
Asking Amount: The equivalent to US $13,000 (using a 30-day trailing average of $POKT/USD price at time of funding)
The goal of this proposal is to fairly compensate @msa6867 for contributions to the $POKT ecosystem (research and development, analysis, technical writing, etc) through March 2023, exclusive of the PIP-22/PUP-21 R&D work already compensated via PEP-44.
Apart from PIP-22/PUP-21 development, @msa6867 has contributed to the POKT ecosystem in numerous ways during the last 7 or so months.
Much of the contribution has led to DAO/PNF actionable results as shown in Table 1, including three approved DAO proposals (PUP-22,29,30) and refinements to methodology for setting the DAO-controlled parameter SSWM.
Other contributions provide more intangible value as shown in Table 2 (e.g., PUP-25 independent analysis, PIP-22 fairness analysis/community education and focused, value-add community engagement both in group and one-on-one settings).
Last, additional research and development threads beyond those shown in Table 1 or 2 either remain open or have been trimmed without action as shown in Table 3. For these threads, no specific value proposition is made, but exploration of such topics is nonetheless an important component to R&D-type engagement.
Taken as a whole, and considering the technical skill required for most of the work contributed, the $13,000 ask (updated due to budget reduction) for this proposal for ~ 7 months of contribution is considered to be reasonable and reflects a much smaller ask, when considered on a per-hour basis, compared to the previous PIP-22/PUP-21 R&D reimbursement approved by the DAO.
The motivation is to apply my systems architecture/engineering background and skill set to add value to the POKT protocol and ecosystem. The contributions made are as an independent party, with no attachment or income source within the Pocket Network ecosystem apart from DAO reimbursements for value-add work. This is an important consideration, in that most of the current contributors to systems-level discussions and governance actions do so as part of their employment with a node provider or other company operating within the ecosystem.
Task-specific details for value-add contributions are highlighted in the Contribution Details and Deliverables section below.
The equivalent to US $13,000, using a 30-day trailing average of $POKT/USD price at time of funding.
There is no single valuation model that is best suited to evaluate the budget. Therefore, an attempt is made to approach valuation rationale from several different angles.
Using Shane’s Proposed Value Model:
The budget represents 56 hours (updated due to budget reduction) of design and development work, using @shane’s proposed value model:
By comparison, the total hours spent contributing to the POKT ecosystem in engagements that led to the actionable results listed in Table 1 numbered several times this value. This does not even count the time spent in the activities listed in Tables 2 and 3.
Table 1 gives estimates of hours spent on each task area. While hours were not meticulously logged as they would be in a hours-based contract, the actual hours spent per task have a 95% confidence of falling within the hour range specified for each task.
Since only a small fraction of total hours invested in POKT research and development over the covered period are requested for reimbursement under @shane’s model, any number of tasks could be eliminated from consideration for reimbursement while still justifying the budget presented.
Using a GRIP-equivalent $100/hour model:
It is a reasonable expectation that if the DAO is willing to compensate the editing of DAO proposals at $100/hour it would likewise be willing to compensate the authors at similar rate for the time it took to write the proposal and conduct the necessary analysis, discussions, consensus-building etc. to drive it to a final successful vote. Using this equivalence method, the budget represents 130 hours of contribution (updated due to budget reduction) . Table-1 hours exceed this value, without even appealing yet to hours contained in Table 2 and 3.
Using PNF impact scorecard for DAO grant proposals:
The budget is consistent with PNF remuneration guidelines contained in the PNF impact scorecard. An assessed score of 20 falls squarely in the range of 10-30 for which grants up to a max of 1% of DAO treasury/$50k is recommended. The $13k ask (updated due to budget reduction) is well within that range.
Using an hourly contract model:
An hourly reimbursement model is a percentage play. All hours are included, even though all hours do not add value equally to the project. Using baseball as an analogy, not every hour spent is a homerun. There are singles, doubles and strikeouts along the way. In @shane’s value model, ideally only “high-value” hours are considered, but those hours are compensated at premium prices. In the “GRIP-equivalent” model, only hours contributing to definitive DAO action are considered. In contrast, an hourly reimbursement model considers all hours, but the rate per hour is discounted from premium levels to reflect the percentage play.
Tables 1 through 3 represent approximately 600 hours of R&D contribution over a 7-month (30 week) period, committing approximately 20 hours per week to the project. This does not include time spent in telegram/discord community engagement. The budget represents a reimbursement rate of ~$22/hour ($13k/600hours) . If table 3 was eliminated from consideration, the hours would still be close to 500 hours, representing a reimbursement rate of ~$26/hour (updated due to budget reduction). For the experience and skill set I bring to the project, this is an extremely fair ask.
Using a flow rate Reasonableness Test:
In the discussion section of several receive reimbursement proposals I have advocated applying a flow rate test to the funding request. The DAO treasury should be managed as one might conduct water management for a river. In the long term, inflow and outflow should be in balance; while the reservoir serves as a buffer to accommodate short and intermediate-term fluctuations. Applying a flow-rate test to all projects helps ensure that the DAO does not become over-extended in commitments.
In the case of this proposal, the budget represents between 5 and 6 days of inflow to the DAO treasury at current emission rates and $POKT/USD price points. This is deemed to be a reasonable and sustainable level of remuneration.
The goal was to foster a collaborative effort to rein in POKT emissions, so as to bring POKT emissions into a range typical for major, legitimate crypto projects and take back control of the POKT emissions narrative from those who continue to decry POKT as “hyperinflationary”. The idea was to move the needle of emissions in the right direction as suggested by the mismatch between the current number of chain and pocket nodes and the minimum number needed to maintain current QoS. It is not the demand-centric approach that Vitaly et al advocated, nor the cut-to-bare-bones approach that Art et all advocated, but rather one that allows for a progressive evolution of supply-side efficiencies. It recognizes the tremendous amount of IP generated by node providers that is subsidized via emissions rewards, and seeks to foster the continuation of such IP generation, rather than decimate it, as would likely happen under more drastic emissions-reduction actions. At the same time, through these measures, inflation will be reduced to single digits within the next 6 months, bringing emissions to a level where token investors can feel comfortable holding unstaked tokens for capital gains without undue concern over how much emissions will cause token devaluation over the coming years. This effort was not meant to curtail the R&D that @Art et al are pursuing but rather to ensure that a minimal program of emissions reduction is in place no matter the outcome of that research . A significant amount of thought and analysis went into shaping these proposals.
FREN collaborators: @cryptocorn, @pikpokt
FREN: msa hours: mid=60 hours; range = 40-80 hours
FREN: msa-specific contributions
• Spearheaded the August Emissions Reduction debate.
• Participated in FREN debate
• Entered into a post-debate collaboration with @cryptocorn and @pikpokt to develop a collaborative emission reduction plan
• Provided the technical analysis needed for the collaborative effort
• Corrected outdated inflation calculation methodology that led to a marketplace perception that POKT inflation was more than 40% higher than actual values
• Technical lead in shaping the final emission reduction plan including:
• Larger initial reduction followed by delay til next reduction to allow time to absorb impact of LP/PIP22
• Alignment of reductions to calendar month for ease of planning
• Switch to simplified “target daily emission” vs old WAGMI “target inflation” to avoid ambiguity in token supply baseline
• Final numbers for reduction sequence ~12% monthly reduction with double reduction first month
• Provided all technical writing for collaborative FREN proposal
FREN: evidence of msa contribution
SER: msa hours: mid=90 hours; range = 60-120 hours (including investigation and consideration of emission reductions alternatives)
SER: msa-specific contributions
• Sole author of SER pre-proposal
• Historic analysis of POKT emissions/inflation since genesis
• Comparative analysis to test and compare various go-forward emissions strategies (including under various system conditions including app burn and overmint)
• Extensive pre-proposal discussion/debate involving @cryptocorn, @caesar and @RawthiL
• MaxSupply R&D for possible future use
• Demand-Centric Emissions R&D for v1 emissions definition.
• Reached collaborative consensus w/ above-named individuals for final SER approach
• Provided all technical writing for collaborative SER proposal
SER: evidence of msa contribution
ACCURATE/PNF setting of SSWM:
The goal was to reduce the gap between target and actual daily emissions. This is important to allow node runners and others to correctly predict emissions and avoid negative publicity in the marketplace in later months if actual supply is found to be much greater than promised levels. Through the above measures, 3 of 4 sources of overmint have been eliminated, reducing average slip from mid-teen percentage levels last fall to less than 2%, on average, today.
ACCURATE collaborators: @cryptocorn
ACCURATE: msa hours: mid=37.5 hours; range = 25-50 hours
ACCURATE: msa-specific contributions
• Sole author of the “Change from Trailing 30-day Average to Trailing 7-day Average for calculating RTTM” pre-proposal
• Provided all the technical analysis for both the above pre-proposal and @cryptocorn’s cadence pre-proposal (which were combined to form the final ACCURATE proposal)
• Provided the technical writing for collaborative ACCURATE proposal
ACCURATE: evidence of msa contribution
PNF setting SSWM: msa hours: mid=60 hours; range = 40-80 hours (this hour range includes the monitoring, investigating and modeling of contributions to overmint that would require DAO action prior to PNF changing methodology to set SSWM)
PNF setting SSWM: msa-specific contributions
• Monitor overmint evolution over several months
• Root cause analysis to break down POKT overmint into constituent pieces:
• Triage overmint contributors into, DAO action needed, PNF-direct action needed and monitor only
• DAO action needed: addressed in ACCURATE above
• PNF-direct action:
• substitute estimator in case Andy script frozen
• subtracting out the saw-tooth bias during long-term direction change of SSWM
• subtracting out non-responsive nodes
PNF setting SSWM: evidence of msa contribution
PNF setting SSWM: deliverables:
The goal was to ignore all the swirl of negative sentiment and evaluate the proposed Ferrum bridge architecture purely on its technical merits. This work was curtailed when it became apparent that the community would not continue with Ferrum no matter what. The technical feedback provided, however, is applicable to future endeavors.
PIP-25 Analysis: msa hours: mid=7.5 hours; range = 5-10 hours
PIP-25 Analysis: msa-specific contributions
The main red-flag that emerged was the proposal to pay validators a cut of the fees collected from each bridge transaction, as this could lead to a conflict of interests for validators. This concern is applicable not just to Ferrum, but also to any future bridge endeavor that POKT undertakes.
PIP-25 Analysis: evidence of msa contribution
The goal was to provide independent corroboration or refutation/alternate explanation to the claims made by PoktScan in framing PUP-25. Many in the community pointed to the need for such independent verification such as seen in these comments:
Outside PoktScan, few in the community are up to the challenge of providing the type of analysis needed. PoktScan graciously released to me the block data and cherry-picker data from the portal in order to perform this independent review. Doing the necessary analysis was a very large undertaking, stretching over two months of near-constant focus and attention. Results of this analysis can be found in Poktscan’s PUP-25 github folder, as well as embedded in the comments section of PUP-25.
PUP-25 Analysis: msa hours: mid=195 hours; range = 130-260 hours
PUP-25 Analysis: msa-specific contributions
• Independent analysis of all block and CP data used in PUP-25 (raw data provided by PoktScan)
• Analysis of repercussions of PUP-25 proposed parameter change
• Analysis of per-region, per-chain QoS evolution over Summer 2022
• Preliminary analysis and analysis methodology guidance for independent third-party experiment to test reward equality across bins
• Line-by-line markup of PUP-25 whitepaper and summaries of analyses in several whitepaper appendices
PUP-25 Analysis: evidence of msa contribution
Other Community Engagement (Telegram/Discord):
The goal is to provide focused, educational, value-add content to various social media channels within the Pocket Ecosystem, including answering technical questions (such as settling debates on how the validator ticket system works), bringing clarity to complex topics (e.g., why v1 is important to POKT price stabilization), brainstorming ideas that later become fodder for working group discussions (e.g., early transition to app burn), etc. Interactions are positive, honoring, encourage contrary viewpoints to be developed, and when critical of past mistakes, remain solutions focused rather than problem focused. In the background I carry on several dm interactions to try to draw out those on the edge of the community into more active involvement and contribution.
Community Engagement: msa hours: untracked
Community Engagement: evidence of msa contribution
For public discourse, please reference primarily the following TG channels: The Poktopus Den”, PoktoPrice, Thunderhead Pocket Network Discussions
For evidence of private discourse leading to encouraging greater community involvement, and/or the fleshing out contrary PoVs, etc., please dm your request, as I do not wish to disclose private discussions in a public forum.
[Note: the following tasks are either still open or have been trimmed without DAO action. The project descriptions and links are provided for the sake of completeness.]
Stake Weighted Servicer Selection Architecture:
Both PIP22 and LeanPocket were community-driven responses to the lack of a true stake-weighted servicer-selection mechanism. Efforts toward the latter stalled due to developer hesitancy to modify the cherry-picker and servicer-selection portions of the code. I explored a stake-weighted selection architecture that satisfies the condition of not touching either the cherry-picker or servicer-selection algos and socialized this architecture to several people. However, the timing did not match community priorities as we were too far down the rabbit-hole of LP and PIP-22 to gather sufficient community interest to warrant pursuing further, and the project was dropped. The architecture drawing can be found at the following link:
Cherry Picker code fix:
The goal is to ensure fairness of selection probability weighting, i.e., make sure that low-latency nodes receive the intended probability advantage over higher-latency counterparts. This is compromised by a pair of code errors that I identified during a review of the cherry picker code and fixed in PR-901. This PR has not yet been merged.
Partial Unstake Pre-Proposal
The goal was to introduce a companion proposal to PoktBlade’s TransferStake proposal to allow partial unstaking of nodes. The goal was to help small node runners compete with large node runners for validator slots if they lacked the deep pockets to meaningfully take advantage of Transfer Stake. This was socialized privately with several in the community, but since the decision was made to place Transfer Stake on hold, Partial Unstake was likewise placed on hold. While The cost-reward balance favors pursuing Partial Unstake if done in conjunction with Transfer Stake, it does not warrant independent pursuit in v0. It remains a useful change and is not beset by the same potential attack vectors that sidelined Transfer Stake. It will be revisited after release of v1.0 and/or will be pursued as an RFP on github for inclusion in v1.0. The pre-proposal can be found at the following link:
Increase MaxValidators Proposal
The goal is to increase network security via allowing 2000 validators. This is well short of the 5000 proposed by @addision last year and should not be subject to the same technical concerns that sidelined that previous proposal. The proposal has been put on the back burner for now due to lack of sufficient interest in the topic.
Raise PIP-22 Ceiling Proposal
The goal is to allow an incremental reduction in overall network cost via an incremental increase In stake-weight ceiling from 60k POKT to 75k POKT. The proposal has been put on the back burner for now due to lack of sufficient interest in the topic.
“xyz task [fill in the blank] should not qualify for reimbursement for xyz [fill in the blank] reason.”
This is a “taken as a whole” reimbursement request that is not tied to any specific task being reimbursed, especially as relates to Tables 2 or 3. An important question to start with is, “would dropping xyz task from consideration drop the hours and value of the remaining contributions sufficiently to warrant a reduction in the budget?” If not, objection to the specific task can be voiced, but should not affect the outcome of the proposal.
”xyz person/team [fill in the blank] only requested and received xyz level of compensation; your budget should not exceed this value.”
Each situation should be evaluated on its own merits, as many different factors play into the equation. The closest other proposal that exists for the purpose of making apples-to-apples comparison is PEP-44 since I was the author and recipient of that funding as well. This proposal represents a much lower request on an hourly basis as that contained in PEP-44.
”FREN/ACCURATE/SER were collaborative efforts. Reimbursement for these efforts should be made jointly.”
I concur that joint reimbursement is best-practice for single-task reimbursement proposals. It is not as practical to apply this ideal to proposals such as this and PEP-51, where remuneration is for a body of work that covers many different subtasks. Further, the ship has already started to sail, insomuch as @cryptocorn has already requested and received reimbursement for his efforts on FREN and ACCURATE.
GRIP assistance was secured to review and shape this proposal via the GaG discord channel prior to posting on the Forum.
Copyright and related rights waived via CC0.