PEP-35: The v0 Optimization, LeanPocket

You need at least 6+ of testing this to make sure it works. It is for the DAO and team to decide how close will they be to V0 in the next 6 months and if this client is worth the $$ you are asking.

I’m so happy that you all are driving forward an outside contribution to Pocket Core v0. I think more community members ought to be adding value like this group is.

I’ve got some thoughts (and charts) to dissuade us that this is the silver bullet that solves all of our issues. No matter how low-cost light clients are, nodes always have a non-zero cost. Leading me to my main point, there is a dangerous assumption in the models presented: node count remains the same with lower costs. This omission paints a prettier picture and ignores one of the key issues at hand: overprovisioning.

A stable node count seems like a reasonable assumption, but let me demonstrate why it isn’t:

The justification for the value provided to the network has to be in question. It must account for the long-term future AND adoption to be valid.

I’ve done some modeling based on the numbers above that paint a more accurate picture of a just light client future. First, some assumptions:

  • Growth % = Percent of node count growth monthly (we’ve been growing at a minimum of about 7% - 13% monthly and higher than that previously)
  • Cost Growth % = Percent of node running costs increasing per month (node running costs rarely decrease). 4% growth monthly over 18 months = $77.92 to give you a scale.

This chart lays out multiple scenarios versus the base case given different growth and cost growth assumption.

image

The base case is blue (nothing changes on Pocket Network). The rest are various scenarios based on growth and cost increases assuming a 50% drop in network costs (using @addison’s numbers). As we can tell, cost can meet or exceed the network that would be stable at 48.5K nodes.

Here is the effect of that over time to network payback:

image

As you can tell, not addressing the core issue of over-provisioning costs the network over time. This proposal in isolation could lead to -ev and much higher actual network costs in the medium-to-long term.

That said, it’s not all doom and gloom. GOOD VIBES has the desired effect on cost savings that @addison was describing in his post, without the risk of spiraling network costs OR betting $2M on the light client:

image

image

BUT WAIT, there’s more: What if you combine them?

image

The combination has the optimal effect on network costs leading to the best possible short-to-medium term answer.

Now to the question of value of this proposal: while there is certainly merit to the client as whole, its value may not be as high as initially requested given the math laid out above. It’s my personal opinion that $2M feels extreme and I’d advise the creators of the proposal to consider something more reasonable for the benefit of the DAO and the future project as a whole.

4 Likes

I have been thinking a lot about the proposed methodology for valuing proposals. I firmly believe that the value-based approach can get out of hand quickly by setting a dangerous precedent for DAO compensation.

Shane sums this up well in his argument.

This value-based approach would have the impact of demotivating the core team or other Foundation contracted service providers. Contributors would be incentivized to work on the sexy, public-facing deliverables, rather than long-term, game-changing solutions. As Shane said, if proposals aren’t treated equally, then most contributors would focus on low-risk, short-term fixes that maximize personal returns.

Let’s look at the proposed logic provided in this proposal in defense of the $2M figure.

The logic, in essence, is impact = value = increased compensation. While I can understand the point, this can be extractive in a system not designed around capitalistic tendencies.

To Mike’s point, the DAO is not designed to provide profit. It is designed to provide fair compensation for work. Further, Thunderhead and PoktFund should be driven by the overall success in the community. Their success should be aligned with, and driven by, the success of the community, not a single proposal.

Whatsmore, the proposers should have a financial incentive to build things like the light client to optimize their fleet of 4,000 nodes. Part of their reward is that optimization in the form of costs savings. The other part can be obtained by open-sourcing and maintaining their solution. Encouraging value-based proposals leads mercenary developers who come for a paycheck, build something, then leave that thing unsupported.

If we believe that this proposal is worth $2M in POKT, then any other proposal that accomplishes the same cost savings would be worth similar amounts.

PUP-15: GOOD VIBES - A New Economic Policy for Pocket Network - #23 by adam accomplishes similar cost savings in a parameter-driven way while having the added benefits of less inflation (more value) and it eliminates the overprovisioning problem.

To the supporters of the value-based model: is PUP-15 also worthy of a $2M+ grant?

I do not think so. You would be hard-pressed to argue that the cost savings/value are markedly different, and according to my last comment, the outcome is actually more predictable.

3 Likes

OK. so you fork Pocket into a private repo and do the easy part of the job, then you “test” it on your own fleet and significantly lower your operating costs. All good so far, a bit risky if the software gets out because the hard part (making it work as a consensus participant) has not been done and it appears that you have no intention of doing it. So it’s a bomb waiting for a match if validators get a hold of it.

So… you hold your closed source software in the dark and ask for $2,000.000 USD before you allow anyone to see it. All good there too, I’ve seen and participated in DAO’s that have paid a ton of money for sexy sounding proposals, so you might get the payday. We’ll see.
I do have a bit of an issue with this line:

“starting to assist with QA”? Come on man, They fucking handed you the fix that you need to make this code compliant and safe. But your super qualified, save the network, purely altruistic team can’t be bothered to submit a PR or even show the code to the team who is supposed to fix it and support it from now on.
If it actually was a request for reimbursement (as it claims to be) and it asked for a number which was based on the costs incurred, I’d likely be in favor. But this proposal is neither of those things.

I am disinclined to acquiesce to this request.

1 Like

Hello Ben,

Thank you for sharing your critiques. I have a few thoughts and comments outlined below. I feel that we have a bit of a misalignment.

No part of this job is easy… We were told when proposed in march that this would require months of a full-time experienced team, require a full rewrite of v0, and not finish before v0. We took this on ourselves to solve this complex problem.

We stated in our proposal that we are working on this. I’m not sure what made you think this.

Per our proposal, validator functionality is a component of the final deliverable.

The 5% is a sign of good faith as they are helping us with this endeavor. They are already compensated to develop pocket protocol. This is a two-sided effort. They identified this vulnerability, Poktblade created a design doc, and Andrew implemented a prototype. Admittedly should have been more clear about this last part in the proposal.

I am not sure where you gathered this notion. We outlined in our proposal that we are only to be compensated upon delivery of a QA-tested, production ready client. The DAO ultimately makes this decision, and receiving payment after completion is what is outlined in the proposal. Thus that would happen.

I would like to add as well that there was a lot of pressure in the community to get this proposal to print. There are a lot of folks who are considering closing their operation and in the interest of time, we push forth this proposal with the best interest at heart. The narrative shouldln’t be changed to a negative issue around pricing which loses sight of the fact that something needs to be done. We are trying our best to help the community and frankly, your comments don’t seem to address any of the positive from this. If it was so easy, why aren’t there 15 proposals on a light client? I think we should relax and have a certain amount of faith, that we will find the right number, the right time frame and the right package that is both efficient, effective and acceptable.

I’m a bit sad that our proposal was seen this negatively. This proposal and what we are doing is completely unprecedented for our network (and probably decentralized governance as a whole). This proposal mainly served as a mechanism to show the community what we are building, be transparent with our goals, and start discussions around retroactive funding.

We are actively discussing this proposal now with the high-level commenters above. While we understand that many are upset with various market factors, we are presenting a level headed approach. We expected constructive criticism from this proposal, we expected debate but we did not expect the narrative to be so negative. Nothing said by the other commenters was unanticipated, but there’s a big misalignment between what our proposal says/what we stand for and your comments.

This was proposed for the good of the community. This helps all node runners out there, big and small. This helps all token holders having to pay for our massive network. This benefits the entire community and ecosystem. I understand the pushback against the economics since a contribution like this is unprecendented; however, I do not see how this warrants such a response.

Regardless, we will continue to build.

I’d be happy to discuss this with you and how we can make our proposal more clear. We are still focused on building the client, and we plan to be compensated after it is delivered. We have a small team that is working endlessly on this and I agree, we should be renumerated for our effort but there needs to be recognition for innovation and magnitude.

There’s been tremendous intangible sacrifice in order to put this forward. Especially Erick who works extremely hard to build this as fast as possible. No one understands this because they didn’t do it. I’m still in high school and run a company that manages almost 4000 nodes and nearing 20m pokt on behalf of thousands of people. I work around the clock managing a team, our community, and my other commitments. We’ve started FIAGdao to make the pocket ecosystem more robust with tools and products that hopefully you’ll be using one day. The light client is just Part 1 of this initiative. This light client has taken a significant amount of my attention away from school, my business and all the fruits of my labor to do something that was deemed impossible. The same goes for Poktfund and their other business initiatives. I strive to improve the ecosystem and innovate and it is unfortunate to have to read this type of response.

More to come and thank you all for taking the time to leave us feedback. I do appreciate it and it means a lot.

To those other responses above, we are continuing to build and think deeply about those ideas. We’ll respond in the near future after we process, lots of data points. This is all new stuff and we appreciate the feedback and support.

4 Likes

I was under the impression at InfraCon that the code had been shared with the team. At the start of this proposal I was under the impression that active QAing of that code was underway with the team. I had then later assumed that the feather branch was created from the LeanPocket code. Consider me now trying to put everything into how I see it now.

I originally thought this proposal was for a code complete client. Then @luyzdeleon shared the link to the feather branch, a code complete client that was done by Andrew… but I still assumed it was an ported from the LeanPocket code. Now I realize that what was shared with the team was a design spec by @poktblade and not actual code.

So the coding/engineering for the feather client prototype, which is in QA, was done entirely by Andrew. That is an important detail to me.

To be fair, this proposal sounds like a two-sided effort with a enormous one-sided reward. These are the questions that come up with your framing:

  1. Is the ask that the DAO choose to greatly favor the team who did the incomplete design spec and partial prototype, over the team who finished the design spec, code-complete prototype, and lead the QA efforts?

  2. Is the DAO suppose to grant reward favor to the TH team because the other devs get salary wages already?

  3. Doesn’t TH have income already too from being the 4th largest node provider and the original OTC market? Why would the DAO not consider TH income for this proposal and only consider the salary wages against the PNI developers?

I’m sorry but 5% does not sound like “good faith” from the DAO. The DAO is supposed to be impartial to all contributors which is the argument I’ve been trying to make. I feel that for the DAO to have good faith towards contributors, it needs to consider all contributions involved when providing rewards.

Again this makes it sound like validator functionally is something your team is going to be doing in the final deliverable, but as @BenVan correctly stating, Andrew already did all the work with Tendermint for you. I do not agree with your framing here.

I’m also confused on what the final deliverable is. @luyzdeleon laid out exactly how the core-team will work with you to integrate and QA the prototype… and so far his entire post has been ignored.

Are you going to be releasing LeanPocket as a competing client to the pocket-core feather branch? Are you asking the DAO to pay for what is now an incomplete, 3rd party client that requires the team to complete, QA, and maintain? Or is your team going to be working with the core-team on bringing the feather branch to production?

I think it’s important that we get into the weeds here, as these details matter.

I don’t believe the team ever said this was impossible, but @Olshansky did state that it would likely be a large undertaking and detract from v1. I appreciate that your team took this challenge upon yourselves to start the ball rolling with the initial design. I’m also thankful that the core-team took that initial design to heart and created a code-complete prototype which they want to work with your team to QA in a collaborative manner. That is how open-source software works… the community shares in it’s development for the benefit of all. TH will be saving millions of dollars a year on infrastructure costs, along with the rest of the ecosystem.

@BenVan made some important points and distinctions. I understand where he is coming from because I’m still piecing things together myself. I’m glad these details were brought to light so we can give the proper credit to every contributor involved and better define what this proposal is for.

While I still feel confused, this post is my attempt to piece together the important details in a good faith, constructive way :slightly_smiling_face:

Suggestions

  1. Share the design spec with the community that was given to the team.
  2. Open-source the LeanPocket client since the core-team already open-sourced their code-complete prototype (though I’d suggest a disclaimer that LeanPocket is not production ready)
  3. Clarify if this proposal is to produce a 3rd party client to compete with pocket-core, or if the feather branch of pocket-core will be the focus.
  4. If it is a 3rd party client, then define if the core-team is expected to continue to contribute to it’s development and help with QAing.
  5. Restructure the proposal to represent the sacrifices put into the creation of the design spec and PocketLean code.

I truly am greatful for your contributions that have now impacted pocket-core. I hope to be able to vote on a proposal that addresses each sacrifice your team has made and give credit to each contributor involved :slightly_smiling_face:

6 Likes

On the topic of the valuation, I’d just like to add a small point as I’ve not seen mentioned: Any good or service is ultimately worth what people are willing to pay for it.

There are currently just over 48000 nodes on the network. So in order for this client to be truly worth $2,000,000, it would require every single node on the network to pay a license cost of roughly $40/node. That amount seems obviously non-viable to me, awesome though this new client does appear to be. :slight_smile:

1 Like

First things first, well done @addison @poktblade @Poktdachi @pierre - you saw an opportunity with a high potential pay-off, and persevered, notwithstanding the uncertainty of the outcome.

This idea would have just fallen by the wayside in an ordinary organisation. But, thankfully, Pocket is no ordinary organisation! DAOs win when they create the conditions for a broader group to participate than is possible under a traditional org structure.

Before getting to my thinking on this proposal, I think there are many things to unpack wrt this thread as a whole. Namely - in my mind, at least - the following:

  1. How we communicate with each other

  2. How we come to decisions as a DAO

  3. How we value work

How we communicate as a DAO

So much context is missed when not addressing someone face-to-face that principles like non-violent communication are essential. Maybe it’s just me, but I felt a lot of heat in the comments on this thread. Heat, which I would have felt triggered by if I was the original poster.

Look back at the FAQ for this forum - FAQ - Pocket Network Forum

We all need to remember some of the core principles of this forum:

  • Be Agreeable, Even When You Disagree and

  • Always Be Civil

I don’t want to go line by line through every commenter’s text, but I think we can do better and approach feedback with more compassion.

How we make decisions

It would be helpful to formalise the fundamental principles of how we discuss proposals as a community, as I feel that some of the comments in this thread are missing the wood from the trees.

I personally take a lot of inspiration from sociocracy in my thinking around decentralised decision making. I appreciate that all votes are ultimately subject to voting by DAO members. Still, to push a proposal to a vote, I believe that the community members should not object to the proposal at hand, i.e. it is within our range of tolerance while ensuring we prioritise progress over perfection. And, of course, any proposal must align with our values as a community.

We should also take it as a given that no proposal is ever a fait acompli. It’s the starting point of a discussion with the community, with time allocated for everyone to ask clarifying questions and suggest amendments to any proposal, and for the proposer to have time to respond to the discussion points and reformulate the post as many times as is necessary to overcome any substantive objections that would make it unsafe to proceed as drafted.

Instead of asking, “is the proposal perfect?” We can ask, "Is it good enough for now, safe enough to try?"And when we object, a sound objection should argue that a particular decision will irreparably damage or reduce our ability as a community to achieve our goals. When this is the case, it is crucial to object to the proposal as it stands, and to suggest a change that will make it safe to try for you. This may require the proposer to reduce the scope and scale of the proposal considerably, and that’s okay :slight_smile:

Applying a framework like the above to this proposal, I think @luyzdeleon did the best job of explaining why the proposal doesn’t work as it stands, and how he would be comfortable with it. Points I 100% agree with, which need to be clarified before this proposal moves to voting, IMO.

All of the other objections are about how much the DAO should pay for this work. Instead of just saying $2m is too much, we should give opinions on what is an acceptable range for this.

In addition to the points from @luyzdeleon (as well as suggestions 1-4 from @shane in his most recent post), I also object to the proposal as it stands based on the asking amount.

Which brings me to…

How we value work

I agree with @o_rourke about not making every proposal for profit. However, I’ve said before on different forum posts that we should overpay our community contributors as we want the best people to devote their time and skills to Pocket Network without necessarily joining the core team.

Comparing this proposal to how much core devs get paid is beside the point. It’s comparing apples with oranges. Each core team member has POKT grants and wins from any successfully implemented proposal that brings value to the network. Contractors always get paid more than employees. And specialised work gets paid even more than that. Particularly when a lot of independent thought and research has gone into it. We need to encourage risk and reward innovation to thrive as a community.

I also have to admit that I don’t like the Proposal value model from @shane - I find it too corporate and overly granular, aspects that most community contributors want to avoid. And are a turn off for many. We don’t have enough high-quality proposals, so we should aim to encourage more, not less. We should also strive to take some risk in funding proposals to benefit from the upside versus trying to overly protect the downside. The joy of retroactive public goods funding is that we can see the product out in the wild first. And reducing every contribution to a $ amount per hour is overly reductive. Yet, trying to charge a rake on the overall value that could be created by a community contribution is overly extractive. We don’t want to create a culture whereby every piece of open source code in the community has a cut associated with it. We can put a premium on novel impactful work, without creating a tax on future value creation.

Saying all that, we should still use benchmarking to understand if we are completely overpaying. And any payment should also be made in light of available DAO funds.

In terms of benchmarking, high-quality protocol engineers get paid a lot. (I’m very happy to provide data points from across our portfolio, if helpful). Provided this proposal is appropriately specced out and implemented in line with how the protocol team deem necessary, then we should pay well for this work. In addition, having more teams working for the protocol outside of the core team will make Pocket more sustainable in the long run. And if we have to pay more to core contributors over time, that’s also fine. But is an entirely different point to funding this proposal.

However, I object to funding this ask for $2m at current prices. This is simply way too much for this one piece of work given how massively undervalued POKT is at the moment.(The fair value of POKT right now is likely around $1, and we all expect it will be much higher in the future.)

I appreciate the proposal for including a vesting element along with a cliff. Still, I would more comfortable with an ask of around $400k at a price of 20c per POKT that has a 3 month cliff post delivery and 15 months of linear vesting thereafter.

This gives massive upside to the contributors without causing too much of a drain on the DAO’s treasury.

9 Likes

[deleted for the avoidance of further derailing the conversation]

1 Like

Thanks so much for your thoughts here @Dermot. The way most are providing “feedback” - especially with regard to the proposed value is truly concerning. I personally think it’s easy to justify $2M for this proposal. However, I also understand and appreciate that others might disagree. But the way these disagreements are communicated could end up costing Pocket a lot more than $2M in the long-run.

The best way to drive talented people away is to tell them how little their contributions are valued. Tell them what they did was “easy” when nobody else saw the solution before they made it so clear. Tell them their time is only as valuable as everyone else’s time - even if they are willing to push a little harder. These kinds of comments and beliefs concern me way more than the cost of this proposal.

Thankfully, I believe @addison, @poktblade, @Poktdachi, and @pierre will overlook most of these comments and push forward despite the negative pushback. However, other talented people might not be as inclined to do so. Pocket has an incredibly talented core team and some equally talented people in the community. If we ever want to see a multi-billion dollar market cap, both need to be embraced, encouraged, and supported.

6 Likes

I would like to reply to this thoughtful response from @Dermot.

We all know (especially in moments like we are in today) that money makes people emotional. We have all kinds of FEELS about it, what it should be for, who should get it, and how much. Compensation and alignment of incentives is literally the name of the game we are playing here and it’s devilishly hard. Public companies spend inordinate amounts of time trying to figure out a CEO’s compensation so as to best align her incentives with that of the overall organization. Not as easy as you’d assume.

Let’s follow the lead of Dermot here and look at this proposal and the response to it as a learning opportunity for the DAO and the community. Proposals start conversations. Conversations should be civil, kind, and supportive. We have here a team headed by two extraordinary teenagers who’ve already done amazing things for the entire community - while managing to keep up with their other obligations in life. To come at @addison @pierre and the TH team’s proposal with accusations and vitriol is completely inappropriate and signals to me that we are getting emotional about money as opposed to discussing this rationally.

There have been some great contributions in the thread that were more focused on moving forward, but let’s please seize upon this moment as a DAO and community to remind ourselves (as Dermot said)

How we communicate
How we come to decisions

And moving forward…

How we value work.
This demonstrates that we need to work on defining this better. I agree with Dermot that straight hourly pay and corporate-style assessment and compensation are probably very “unsexy” to young talent whom we’d like to engage. If outside contributors wanted to paid like they worked for corporate, they’d be working for corporate.

That said, there are many ways we can compensate contributors that are aligned with long-term support and engagement around what they’ve created. @o_rourke suggested some, @Dermot suggested some.

THAT SAID (and now I am SHOUTING a bit) - most of the comments that I considered to be less than productive did ignore the fact that bringing the cost of the network down IS extremely pressing and while it’s not solving for over-provisioning (IMO), it is still incredibly important and timely.

I don’t believe we should wait to move forward on LeanPokt while we argue about compensation models for the long-term. I’d like to see us come to some agreement on the compensation of this one now, whether it turns out to be our “How we value work” solution for the long term or not.

Let’s keep it civil folks. Assume good intent, especially from those who’ve demonstrated it in the past.

2 Likes

It is absolutely amazing to see so many collective individuals come together and drive discussions, paving the path for future DAO proposals but also the future of Pocket Core. It is a further testament to how bullish I am for the Pocket community and the ecosystem for years to come.

Everyone’s comments are heard loud and clear, and everyone who has posted on this proposal has invited thought-provoking comments and concerns that we are taking into account. Nobody will be left “ignored”, these types of conversations take time to digest, though I am going to provide some clarity on the engineering aspects and value from my POV.

To give you a better perspective of what it looks like to contribute to V0 right now, and the reason why the proposal (in technical aspects) is formed the way it is today:

  • The documentation is lacking in all directions for contributions.
  • The protocol documentation is sparse, leaving up the Github source as the single source of truth on how the protocol works inside out. I spent months reading this code inside out before making changes, and if you combine that with @addison and @pierre efforts, that is a plentiful of months, man hours, spent learning about V0 protocol.
  • When making the light client, the local net was broken - making testing even more difficult
  • Setting up a localnet E2E stack is even more ambiguous - even some folks on the PNF side find it confusing.
  • There is little information on what Q/A testing looks like for external contributors
  • Lack of channels on how to receive help for external contributors

The reason why I outline the above issues is that it is crucial to understand how difficult it is to contribute to V0 as an external developer right now. It is my belief that the Core team did not intentionally set it up this way, and they are now in a process of fixing this since we revealed LeanPOKT. A startup that grew as fast as Pocket Network combined with a lean-agile engineering team can understandably lead to gaps like the ones I outlined above. There is no one to blame, here, and I am extremely proud of where we are today. Though, I must disagree with some of the @luyzdeleon approaches for contribution at this time, as the external contributors’ efforts currently being set up are a reactive measure that can be deferred for another time. We could get this out much faster if PF, TS, and Core work in tandem to come up with architectures, testing & release plans, etc instead of siloing out the work in the form of “multiple prototypes”. In the near future after the sense of urgency has died down due to external factors (market), we can revert back to improving the processes for external contributors from what we learned working together.

It is also important to highlight we must recognize the individuals who innovated and brought this thing to life, and that would be PoktFund and Thunderstake. The hardest part of any important task is getting started on it in the first place. It is my belief that the Core team had no plans to implement such a change until @Addison elaborated on the implementation details of our light client at Infracon. This was clear to us whenever the core team presented V0 optimizations that included mostly single-node optimizations. Once the idea was clear and it was driven possible by our team, of course, the Core team would be able to incorporate this as well (in the form of a prototype), as they have years of experience making changes to the V0 core code. These prototypes were made to support us, not over take our work. But let’s not forget the journey it took for the external developers to be able to proactively identify the need, reach our milestones, and prove the feasibility of such an engineering feat.

Now we are at a crossroads in which I have large faith that the Core team and us will work this out and drive further collaboration that the Pocket ecosystem has never seen before. I see this as an opportunity for one of the first external contributors to work alongside the Core team to bring you the best v0 Core client release you’ve ever seen before while improving the process of contribution in every area possible. This is great news for Core, Pocket, and external contributors. This proposal should never derive into a conversation about how much Core members are paid, what work Core did in comparison to others, and so forth. This is a community effort that we will get past leaving investors, node runners, and community members with the most significant cost reductions since the genesis of Pocket.

We will continue to build.

5 Likes

Is there a publicly available GitHub repo/fork where this work is taking place? I’d love to follow the development as it takes place.

2 Likes

Hi iaa12,

The teams are working on a process right now that will give everyone more insight into the progress of this proposal along with a mechanism to follow along. I would expect an update to be posted in the next 24 hours that everyone should find helpful.

Thanks,

Sevi

2 Likes

Hey all, I’m pleased to share that the Thunderhead and Poktfund teams have aligned with the Core Dev Team on the appropriate process to follow for an external contribution to the Pocket Core client.

For context, we just launched a more robust process for external contributors working on v0 client enhancements to collaborate with the Core Dev Team. All external contributors are expected to follow this process, whether they’re contributing a code refactor, stake-weighted selection algorithm, or a light client.

Due to the special circumstances of their proposed contribution to the client – it is expected to reduce costs during a period in which many node runners are at breakeven or making a loss – we will be following a modified version of the standard contribution process. In particular, the contributions will be kept in a private repo that only the Core Dev Team and external contributors will have access to, it will be tested privately, and then open-sourced only if/when the client is confirmed to be ready for mainnet adoption. If another contributor were to come along with an alternate light client, we would take the same approach with them.

The next steps for getting the contributions ready for release are as follows (^ marks steps that the Core Dev Team are supporting with, as they would with other external contributors):

  1. Share the private repo with all Pocket Core Dev Team members (:white_check_mark: done last night)
  2. Integrate the validator components from the Core Dev Team’s feather prototype with the LeanPocket prototype^
  3. Submit the LeanPocket design spec as a “proposal issue” to the pocket-core repo, as expected from all external contributions (in progress here)^
  4. Get to code-complete status^
  5. Define feature-specific scenarios that need to be added to the provided QA suite^
  6. Run QA/testing and submit a report with results of tests
  7. Provide necessary documentation for the community and future client developers to understand the feature
  8. Define deployment plan^
  9. Private Testnet Beta rollout (to a sample of nodes approved by the Core Dev Team)^
  10. Private Mainnet Beta rollout (to a sample of nodes approved by the Core Dev Team)^
  11. If deemed by Core Dev Team to be safe for wider release, open-source client and PR to pocket-core repo to be merged with the official client
  12. Public Mainnet RC rollout^

The external contributors will be communicating with the Core Dev Team inside the new #pocket-core-contributors channel and in weekly Core Contributors Office Hours. You are all welcome to follow the progress of this work in those channels.

If there are any other external contributors who wish to contribute to the v0 Pocket Core client, and gain access to these channels, please see the guidelines linked above.

6 Likes

And now I’ll put my governance hat on…

While I’m excited to see the external contributors agree to the standard development process, I don’t feel we’re aligned yet on what is appropriate for governance or, more precisely, the specifics of the grant mechanism. As with previous misalignments, I don’t blame anyone for this, rather it’s a result of us being in uncharted territory.

I have some very specific feedback that would apply to any proposal that seeks to adopt this approach to their grant:

  • If we’re calling this a retroactive funding proposal, this shouldn’t go to a vote until the work is complete and the DAO can assess the real impact. Publishing a retroactive funding proposal in advance of completing the work is bad practice because it just leads to speculation and disagreement about the fair value of a contribution, as we’ve seen here.
  • If you’re going to include a cliff/vest, there should be clearly defined terms of termination, e.g. in the case that the work is not delivered. You’re promising future contributions, such as “commitment to support” and delivering “technical talks” and “design documents”. What are the accountability mechanisms for these promises? Does support include an SLA? Should failure to deliver on these promises void the cliff/vest? If you or the DAO do not feel comfortable with the can of worms that this opens, or with answering how a dispute over terminating the cliff/vest would be resolved, then we either should remove the cliff/vest and any deliverables that have yet to be delivered, or we should make this a true retroactive funding proposal and not vote until all deliverables are complete.
  • If we’re using a cliff/vest, considering how volatile the token can be, it makes no sense to denominate the grant upfront in $USD, a practice typically reserved for situations where the contributor has specific development costs they plan to cover (as was the case with Poktfund’s latest mobile wallet proposal). $2M at today’s prices could become $200k ($0.015) or $20M ($1.50) at any time during the vest. Considering we’re at an all-time low price for the token in public markets, it’s more likely to be the latter. If asking for a $USD budget and applying a vest, the tokens to be disbursed should be calculated at the time of each vest, not upfront. If you believe enough in the future fair value of POKT such that the previous treatment sounds unattractive, you should just ask for a POKT-denominated grant.
  • The DAO should not be staking tokens on behalf of grant recipients. This is not a can of worms I feel comfortable opening.

With the above critiques in mind, I would recommend the following next steps for your proposal:

  1. Rescind the current proposal and focus on delivering your external contribution according to the standard development process laid out by the Core Dev Team.
  2. If/when the light client has been approved by the Core Dev Team and released on mainnet, submit a new PEP.
    • The new PEP should be budgeted in one of 2 ways:
      1. USD-denominated, with vesting amounts calculated using the price at the time of the payment, not upfront,
      2. POKT-denominated, with a fixed amount upfront that unlocks over time, independent of POKT price.
10 Likes

I thank everyone for their contribution to this discussion, particularly TH for getting it started.

In general, I support the development of a light client (though I am not sure about its priority vs. stake weighting). But to me, this discussion is more than a specific code change. For me, it is about how we engage with our community.

I support (&LOVE) community contributions. In a lot of regards, we will be engaging with community for the first time in this scale. That’s why we should set a very good example. Since this will set the tone going forward, let’s start with HIGH standards of business conduct. The minimum for proper business conduct starts with openness, prevention of conflict of interest, fairness, clarity, measurability, ownership and legality. Most businesses meet their requirements and achieve these standards with an open and fair bidding process. We should do the same.

I propose that
1\ Pocket core team outlines detailed specifications of what is the best interest of Pocket project, and where exactly they need the help. This can be quick, because they are already pretty up to speed.
2\ Specifies the needed help and put forward a reasonable yet measurable set of performance goals and success metrics. What are the deliverables? What does the maintenance window look like? What are the consequences of not meeting project goals in terms of dates, quality, perf metrics, etc.?
3\ Specifies the selection criteria (price and other metrics) and open it to public bidding
4\ Gives a brief but reasonable time to participants for preparing their bids. Sends it to DAO for approval of the selected proposal.
5\ In any case, regardless of who does what, the buck stops with the pocket core team because they have a) a proven track record, has the context of past (&costly) mistakes, b) an understanding of future direction c) is altruistic without any intrinsic favor to any person or company. Pocket team should own the direction, the dates and the quality. Full stop.

Right now, per Jack’s message, it feels like we already bought something, with price TBD and without clear deliverables (no clear timeliness, measurable success metrics, quality assurances and compensation clauses if they are not met). That’s not ideal. Would you commit to buy anything yourself with these unknowns? I wouldn’t.

WRT $2M price tag (on top of what Jack said so well): Yes, light client development can be a money-saving proposition, but is it really worth $2M? We don’t know; because as mentioned above, there aren’t any clear criteria of what will be delivered, at what quality, at what timeline, per which requirements. Also, there may be other alternatives (like stake weighting) that can achieve at least comparable savings and be less implementation dependent. But my gut feeling is that the asking price of $2M is unreasonably high. Being in crypto, sometimes it is easy to lose the sense of the real world. Just to put things in perspective: $2M is 37 years’ worth of average US salary. Please, don’t tell me that this proposal creates more value than an average person does in 37 years of their prime working life. This proposal is priced based on the value it offers. That’s a slippery slope. For example, for many weeks, we’ve been offering to be an early beta tester and we didn’t even think of asking for compensation. Now we start to think maybe we should have. If beta testing in our large fleet detects a serious bug, and prevents even a single-cent price drop, that’s worth $10M. So should we be paid $10M for our beta testing efforts? See, this kind of pricing approach breaks down quickly.

I support (and LOVE) community contributions. And I also support compensating them fairly. But the original proposal has some very serious shortcomings in terms of clarity, in terms of high $$$ and in terms of how it is asked to be awarded.

We can do better than this. Let’s explain this requirement (I want to see a write-up from the pocket team why this is a higher priority to stake weighting) and put it to public bidding. Give our community choice, and a fair chance to decide who does what for how much.

8 Likes

Stopped reading after:

‘‘We are asking for $2m USD in Pocket upon completion.’’

1 Like

‘’ Since this will set the tone going forward, let’s start with HIGH standards of business conduct . The minimum for proper business conduct starts with openness, prevention of conflict of interest, fairness, clarity, measurability, ownership and legality. Most businesses meet their requirements and achieve these standards with an open and fair bidding process.’’

I wish you would extend your views on high standard of conduct onto your rewards share program. While Pokt prices were high, your organization required minimum 10 nodes for monthly direct USD payment staking method and asked single node stakers for rewards share in order to maximize your profit. The moment your business has started to break even, you email your users and tell them you have changed the rewards share percentages as you see fit. Perhaps it is within your right according to the sign-on agreement, I haven’t read it, but that doesn’t make it ‘‘high standard of conduct’’.

High standard of conduct is where you give an option to your stakers to directly take out their 15k without waiting for unstaking because you decided to change percentages, you should bear the cost of unstaking period. Or warn your customers about the percentage change 21 days prior, and continue operating at marginal loss for 21 days if need be, which would have been well compensated by the opportunist high rewards share options you pushed on small investors.

I see the the same utilitarian opportunism in your conduct of business as the posters of this PEP.

Thank you all for the feedback and taking time to lay out your responses. Some were definitely more negative than we anticipated; however, many were constructive and helpful. I/we are generally new to decentralized governance, and on top of that this is a contribution that has no precedence within the Pocket DAO. Per Jack’s suggestion, we have rescinded this proposal and will worry about a future proposal later. In the meantime, we are focused on getting the client to code complete and starting QA so that we can get this out to the network safely and as fast as possible.

9 Likes