[PREPROPOSAL] PoktFund 2022 LeanPOKT and Security Vulnerability Reimbursement

We can all agree to treat these contributions separately. In the interest of moving forward on proposal structure (and despite my empathy on feeling the need to defend yourself against character attacks), let’s focus on getting this proposal through the process and up for a vote.

4 Likes

I think we should give space to the teams involved to navigate as they think best. I personally don’t see major challenges in contributions being accounted for in separate proposals.

A philosophy of PNF is “Partnering, not Parenting”. Teams should feel safe to express publicly or privately if they need support in navigating difficult topics, but I don’t think we should rush to legislate harmony and I do empathise that some challenges maybe stem from not having someone like PNF around to support things in the past.

I agree navigating conflict is an important topic, but I think it’s a skill we all should be working to develop in ourselves, so we can express our grievances and resolve them in a mature way without being hushed. DAOs are powered by competing points of view and some tension is always likely to be present

8 Likes

Just out of curiosity, who wrote the majority of code? Should be a pretty straightforward path to compensation?

We strongly support this proposal because everyone reading this message would be underwater if leanpocket never happened.

3 Likes

While I respect the thoughtfulness you always bring to the table, I have to ask, does this comment have anything to do with evaluating this proposal by itself on its merits?

The Poktfund team has submitted a preproposal for reimbursement based on the efforts they put in. They’ve indicated that they are operating separately from Thunderhead on this proposal. I don’t think this proposal requires trying to assess the varying values contributed, or the various agreements that third party vendors in our ecosystem might have tried to establish.

To be frank, your comment feels inappropriate.

I would love to evaluate a separate proposal for Thunderhead’s contributions, but that is separate and distinct from the proposal put out here, and some of the comments (frankly) feel like an attack on this proposal.

All contributors in the space deserve having their contributions reviewed on their own. I would like to see some mutual respect in approaching these proposals on that front.

3 Likes

i read Sevi’s post, no ill will there. Anyone can come to any forum post and say what they like and explain the situation.

Facts of the matter to me were that PoktBlade and crew wrote 100% of the LeanPOKT code. Thunderhead did all of the in production testing.

I been telling both teams in separate chats that the splits should be 65/35 PoktFund. Let’s get this shit passed and keep it moving.

3 Likes

You guys can’t flip flop on these things.

Doesn’t matter if they have companies with a substantial amount of $Pokt staked.

We want the best engineers working on the hardest problems.

You also can’t time this. Crypto moves fast. We had our own version of Geo-Mesh that maybe we wouldl have open sourced eventually. PoktScan beat everyone to it.

Pay the builders!!! All of them!!! LFG!!!

1 Like

Sorry but I don’t see any contradictions. In fact I believe what I wrote in the other threads is relevant, so I encourage everyone to check them out if they don’t understand my perspective.

I stand by both statements and I’ve been very consistent, possibly to a fault, despite folks having passionately disagreed with me. I believe that value for proposals should be based on measurable metrics. I’ve been very consistent with that and even took pushback from my team’s very small proposal and create the Proposal Value Model (sorry for referencing it again, but hey, I’m constant :wink: ).

I feel it’s a service to the community to make value tied to measurable metrics, because then if there is any questions or disagreements you can point to something and say “I don’t understand this” or “I don’t agree with this” without having to disagree with the entire proposal.

I don’t disagree with is proposal, but I do think it’s worth fleshing out how the value is being measured. While I appreciate you are quick to want get deserving contributors paid, I disagree with the approach of abstract evaluations that don’t scale.

I agree with the sentiment of “Pay the builders!!!”, though I’m still interested in keeping true to scalable standards, even if it means saying the same things, hopefully with maturing elegance, over and over again :wink:

4 Likes

We (POKTscan team) think that it is very difficult to give this proposal (and others like GeoMesh) a measured and detailed accounting of why are they asking for X amount. We have the same problem ourselves as TH or PocktFund. We are not dealing with bug fixes or bounties; innovations are hard to measure.
I would love to have the answer to how much LeanPokt is worth. It’s no secret that I hate arbitrary numbers. The problem I see is that even if you could put a price on:

  1. each line of code. (lines of code do not relate to effort! :angry: )
  2. each minute used for R&D, marketing and support.
  3. measure the cost reductions for the whole network. (how do we really know the extent of LP adoption? it has no footprint on the block-data)
  4. the value of coming up with the idea and implementation.
  5. the value of acting against self-interest and open-sourcing a product that helps your competitors. (the DAO must value this and encourage this behavior)

Even then the number will be the product of many other arbitrary values. Innovation is not easily measured, even less so R&D (there are lots of papers about this and lots of angry academics). I think that we should not try to go too deep into details of value. If what they ask for makes them happy and the DAO thinks it’s an acceptable price, we should go forward. If the DAO thinks it’s too much or too low, we can discuss why.

5 Likes

Yeah, I understand it is difficult. Truly… I have submitted a number of proposals, and helped many others submit proposals, so I know the difficulty.

I REALLY am hoping PNF is able to start streamlining the process, but while maintaining measurable standards. Abstract evaluations may feel right for this proposal but IMO it doesn’t scale without getting very subjective, very quickly.

Like I said, measurable metrics are a service to the DAO. It makes submitting proposals more difficult, no doubt, but IMO it’s part of the process, especially with very large proposals.

There may be few of us out here, but this is my perspective. I’ve also provided feedback to them off-forum, as I’m not looking to just “disagree”. I’m very glad we are discussing this pre-proposal as they are a deserving team.

2 Likes

I agree on the need for us to figure out more quantifiable systems of assessment, but I wonder if there are effective ways to model cost around a labor calculation with a premium for innovation?

We have around 30K for a high level security exploit, and around 400K for engineering work spelled out here:

If we had an enterprise development agency billing us out at 250 an hour, this cost would equal around 1600 billable hours. So, we have a baseline for comparison there. That’s 20 full time weeks for a 2 person team, 10 full time weeks for a 4 person team. We have over 1600 commits over 10 months in the repo:

Plus document creation, ongoing support, etc.

I don’t think a pure hourly metric is necessarily the right way to go, but evaluating from that perspective does seem to put this in range, versus it being “abstract”.

8 Likes

@Jinx this very much the kind of data points that are helpful! Being methodical about looking at the contribution, the amount of effort it required, the talent of the team, and allowing the voters see the value in a way that compares to something outside of the proposal itself.

For me, this kind of value gauging helps. Much thanks :+1:

7 Likes

Yes, going to agree here. Note: I did try Shane’s value model proposal, but it felt like I was entering arbitrary and subjective values and weights to justify the ask. Interestingly enough, when I was playing around with the values, the end result was actually more than what we are asking for today. That said, I think the model is an interesting experiment - but we are going to refrain from using it for this proposal as I don’t think our team agrees with the measurement variables and weights. There are also concerns about having a level of consistency and asking amounts to prevent any looting of the DAO. This is a concern of many, however, I have full trust that the DAO is able to realize when the treasury burn is too high and come up with solutions (i.e budgets and defining burn rates) to solve them. I believe we should actively continue this conversation but not necessarily in this proposal.

There are also mentions of measurable metrics. In this thread, they already exist if you look for them. They are just in different forms(s) depending on the reader and how they value them. We go into the time frames in which this project was delivered, the GitHub repository that dictates our work, the network adoption that we sampled of LeanPOKT, and so on. Some will value time, some will value impact, and some will value lost opportunities. Heck, even some posters have expressed that we should’ve asked for more. I think all of these variables are equally important, and we should consider all of them. The percentage in which you value XYZ is ultimately going to be subjective. In the end, when you account for the timeframe, impact, expertise needed, and value of such innovation, the ask in comparison to how much the DAO currently has in its treasury is absolutely reasonable in my book. We are not draining the DAO, the treasury is not at risk, and we’re not asking for an all-time high. As a DAO voter, I do not want to be picking and auditing if the XYZ team actually spent XYZ hours or what each commit actually means. I actually lean on the side of valuing impact and dedication, but someone else might not, and that’s okay.

I like the idea of thinking in bets. And when you think about this proposal in terms of a bet, the value that our team will continue to produce will absolutely be worth it for the DAO and POKT.

4 Likes

Interesting. Always down to make it better and see where things are off balance. I agree that it doesn’t cover every scenario, but I’m interested in seeing where imbalances may be to improve it.

Could you share what you filled out?

I’m aware that the model works better for smaller and not bigger projects, but it would be helpful to see the imbalance. You could just share with me privately as well if you wanted. Just looking to improve it if possible :+1:

2 Likes

Don’t want to comment on the main subject, not my concern yet.

But since you pulled this anon out here, I hope that you read his humble reply to Sir Dermot as well :wink:

Caesar’s pride & al you see :wink:

Ok will let you go back to your noble agenda. Great job btw!

2 Likes

I think any time we see multi-million POKT requests we get a bit of sticker shock, but Lean Pocket and Chocolate Rain were two very important contributions to Pocket as an Ecosystem and Blade is one of our most important contributors who we would do well to continue to enthuse in our project.

I support this (pre-)proposal. PoktFund doing some heavy lifting.

3 Likes

Can you please share what from the LP development carries forward into v1. Even if LP itself is not needed in V1 (or is it?), IP, lessons learned, etc, may very well survive. Knowing what survives into v1 and what terminates with v0 may help in the evaluation of the proposal.

4 Likes

V1 is a complete rewrite, only learnings will be carried over. Everything from V0 is a lesson learned for V1. For example, database persistence specifications allow for n:1 processes. Though, we’re not taking credit for any of that either. I’d say the largest value add to the V1 roadmap is probably the people (i.e PoktBlade), the contributors from V0 familiar with the Pocket protocol that can provide experience to improve V1.

3 Likes

tl;dr I fully support the reimbursement of the work done here but believe the asking amount needs to be re-evaluated.

It was brought to my attention why the core protocol team left comments on the reimbursement of POKTScan’s Geo-Mesh but not here.

Most of my thoughts on the asking amount in this comment transfer over to this preproposal as well.

This asking amount will capture approximately 7% of the DAO’s treasury. Not accounting for Thunderhead’s potential reimbursement request, alongside other work the community is doing (Geomesh, branding, marketing, etc…), and given that there is no active proposal to raise the DAO’s allocation from each block (currently at 10%), my gut is telling me that the figure is simply too large.

I don’t have a good answer to what the amount should be, but I know @shane has been putting a lot of thought and effort into this.

5 Likes

Here are my two-cents for what it is worth . I posted almost identically to the PoktScan geo-mesh proposal.

  1. Evaluating funding size in terms of percentage of treasury is good. Even better, IMO, is evaluating it in terms of how much of the inflow into the treasury it represents. The nuance of difference is important, because the first method tends to promote a “lack” mentality (i.e., “once 20 funding requests of 5% of the treasury are approved, the DAO will be broke”) while the latter keeps in the forefront of the mind that the DAO treasury is more like a river flow to be managed to match inflow and outflow. Currently DAO receives approximately 2M $POKT per month. So this ask represents 3 to 4 months worth of DAO budget. (A combined PuctFund/TH ask of 10M for LP would represent 5 months worth of DAO budget). This, to me, seems like the right ballpark for an effort and an impact of this magnitude.

  2. The benefit to the project and the ecosystem of open-sourcing solutions for mutual benefit rather than keeping proprietary to self-benefit cannot be overstated. What behavior does the DAO wish to incentivize. Reimbursing to the level that tells contributors that they will be rewarded adequately for open sourcing will incentivize more of the same in the future. Reimbursing at a miserly level tells contributors that in the future they are better off keeping innovation proprietary and milking every last competitive advantage they can for themselves. To me, the former is a vastly wiser and superior course of action.

  3. Applying the “thinking in bets” idea, also results in the same conclusion. The value Poktfund has brought to the ecosystem is tremendous. This is a multi-person effort and there has to be reasonable reimbursement in order to keep the team together and contributing.

  4. Repeating myself a bit: this is a multi-person effort; some of the comments made to the effect that “we support funding but the ask is too high” are likely not taking into account this fact and instead comparing their salary or contract labor rate to this ask as if it were all going to one person. It is not.

7 Likes

I really like this principles based approach. Aligning on what is valuable, even if we don’t agree on “how much” value was created definitely moves the ball forward. I think Dermot is going to elaborate on this but just wanted to say parameters around public good, utilization across the network and benefit (especially if that benefit is to paying customers!) are some good ones to think about

4 Likes