[PREPROPOSAL] PoktFund 2022 LeanPOKT and Security Vulnerability Reimbursement


  • Author(s): PoktFund (BaaS Pools LLC)

  • Recipient(s): PoktFund (BaaS Pools LLC)

  • Category: Reimbursement

  • Asking Amount: 7M [TBD until actual proposal] POKT


If you do not have context about what Lean Pocket is, we highly recommend reading the blog for Lean Pocket as well as Chocolate Rain security vulnerability. This will help you navigate the proposal with more clarity.


BaaS Pools LLC, also known as PoktFund, is asking for a 7,000,000 POKT reimbursement from the DAO Treasury for the extensive research and implementation efforts associated with Lean Pocket as well as the security vulnerability known as Chocolate Rain. This proposal seeks to highlight the history of the team, the significant impact that Lean Pocket has had on the Pocket Network and ecosystem, the risk Chocolate Rain imposed, as well as explain the rationale behind the requested amount of POKT.


PoktFund was established in 2022 with the aim of making a substantial impact on the Pocket Network blockchain ecosystem. The company has demonstrated its dedication to this goal through the development of open-source applications, such as a mobile wallet and a monitoring utility for node operators.

PoktFund has made a substantial contribution to the Pocket Network protocol by designing and implementing “LeanPokt,” a solution that significantly reduces the computational resources required for node operation by nearly 99%. This optimization has increased the cost-effectiveness of nodes to the network, making it more accessible for a wider range of participants, reducing infrastructure costs, inviting institutional stakes, and pushing for sustainable node economics.

The company has also demonstrated its commitment to the security of the Pocket Network by identifying and reporting high-critical security vulnerabilities (chocolate rain attack), proposing effective fixes, and communicating these findings to the core development team.

In summary, PoktFund has brought a substantial level of engineering talent to the Pocket Network ecosystem and plans to continue making meaningful contributions in the future. We started from a small team 2-3 active contributors and have grown that strategically to 10+ over the course of nearly a year.


Lean Pocket

The PoktFund team devoted significant time and effort to the development of Lean Pocket between Feb 2022 and Dec 2022. The team demonstrated the substantial improvements achieved through Lean Pocket at InfraCon 2022, held in the Dominican Republic. Shortly after, the team engaged in discussions with the core development team to make Lean Pocket publicly available, and it has been available to users as of version 0.9.2 and later releases.

Chocolate Rain

The PoktFund team recognized a security vulnerability where an unbounded amount of POKT can be
minted by “overservicing” node(s). This is a critical level vulnerability by PNI and we were awarded $10k USD (roughly ~90k POKT). To elaborate further on this vulnerability, this meant that a unlimited amount of POKT could be minted under the correct conditions. We tested and validated it on Localnet RC V0.8.2 before submitting documentation to the core team containing all the necessary details to replicate and implement the fix. It was fixed in 0.9.0.

We also led research into reimbursement for bug bounties in which we scrape and normalize data on the rewards amounts in Web3, Please read here for further details.



Initial posts about a light client being possible were skeptical and unoptimistic (see responses here). Regardless, the team saw the potential and opportunity and has worked relentlessly to make it possible. Without the attention of PoktFund, it would not be an overstatement to say this optimization would have never made it to light in V0. Today, Lean Pocket has significantly reduced resource requirements, making it possible for nodes to operate at scale more easily and efficiently. Lean Pocket has reduced infrastructure costs by approximately 98 to 99.3%.

The team was motivated to work on this project due to recognizing the high, unneeded cost to the node running economics. Recognizing the limited resources available to the core development team working on V0, PoktFund diverted existing internal plans and shifted gears to reduce the operational overhead for node operators without breaking consensus. It was deemed important to bring this optimization to the attention of the public in order to avoid a scenario in which competitiveness of node operators would lead to privatization of this valuable optimization. Fast forward to today, this contribution has pushed the frontier to making Pocket a more open space to contribute… i.e. the creation of core contributor hours, contribution guidelines, and so on (Credits to the PNI team for structuring thus, of course). Lean Pocket also made the network more attractive to new participants and laid the foundation for future optimizations, such as GeoMesh (all credits to Poktscan for geomesh of course).

PoktFund has also continued to support Lean Pocket after development through all the beta releases and up until the actual release of v0.9.3. A prime example of this is when the chain was halted due to the non custodial update. Many of the node operators were already running the Lean Pocket optimization, and so the PoktFund team was prevalent to ensuring that LeanPocket was readily available so that consensus could continue.

We sampled at block height 73506 on who was running LeanPOKT and at least 37.95%+ (10218 / 26917 nodes) of the network was confirmed to have adopted LeanPOKT before it was even available as a official RC, proving the urgency needed to save compute and storage costs by the network. (Attached is our snapshot taken)

As of block 84748, there are 11991 out of 22697 nodes who have adopted BETA v0.9.2 or v0.9.3 which is nearly ~ 52% of the network. We believe the actual percentage is more considering node runners have shifted over to Geomesh for economic incentives reasons, but keep in mind Geomesh also incorporates LeanPOKT under the hood - if you account for these nodes, the number sits around ~90%+ of the network (all credits to Poktscan for geomesh of course).

Ultimately, the contribution has had multiple impacts from contribution-friendliness to the entirety of node economics. By saving nearly 99% in costs, the cost to run nodes was significantly reduced - preventing a risk of a complete downwards spiral when it comes to profitability, retail and institutional investments, and so on. We won’t touch base on this too much, but hopefully one can realize the magnitude of the impacts this contribution made to the ecosystem.

Chocolate Rain

For chocolate rain, the motivation is easy to understand and not much needs to be said. If the security vulnerability made it into the hands of a bad actor, the consequences could of been catastrophic and the end of Pocket’s reputation as a network. PNI was prompted to create their own bug bounty program as a result of our whitehat disclosure, ultimately leading to more formalized processes to ensure a secure network. (All creds to PNI for this process.)

Note from their blog post: PNF may also choose to define its own bug bounty program independently of PNI and the DAO. Until PNF has its own bug bounty program, PNI’s bug bounty program will cover PNF-hosted software.

As a followup, we did a fair analysis of existing bug bounties to ensure that our asking amount is within reasonable levels of the current industry market and provide guidance on how we can leverage the DAO treasury to fund bug bounties as well.


The funds being asked in this proposal will be used to reimburse BaaS Pools LLC for the work done between the dates of Feb 2022 to December 2022.

7,000,000 POKT will be disbursed to BaaS Pools LLC.

Dissenting Opinions

Why does this proposal not include ThunderHead in Lean Pocket?

Note: ThunderHead has requested that we remove references to them in the body of this proposal, hence the lack of mention aside from this section. We do not know if they will or when they will submit their version of the proposal. The asking amount reflected is only for BaaS Pools LLC

Rationale: Previously, we submitted a joint proposal (PEP-35) amongst both organizations with the expectation that the DAO would reward us with $2m. This is no longer the case and hence one of the reasons why we’re decoupling the proposal. PoktFund has decided to proceed with this separate proposal-based approach due to the feedback from PEP-35 and how the DAO perceives value.

Clarity: BaaS Pools LLC is a completely separate entity from ThunderHead and does not share any resources or finances with each other. To be fully clear, we did not receive any funds from TH nor did we agree to ever receive funds from them. Our company released LeanPocket for the community with always the expectation that later the DAO would reimburse us for our work. In submitting a separate proposal, we believe this allows for a more granular depiction of the work completed and reflects the contributions and expenses of Poktfund for not only LeanPocket but our security disclosure as well. This in return will provide more transparency to the DAO to make a decision for an reimbursement. This follows a similar structure how MSA and Liquifiy separated their proposals for PIP-22.

PoktFund already profited so much from having a headstart on this optimization.

The company did not seek to limit access to or profit from the optimization as a node operator. We have kept communications open and transparent during the entire ordeal. As a result, this means that we consciously put a hold on starting any node operator/provider business until it was publicly avaliable for use, and missed a large opportunity to capture revenue for months during a vulnerable period when many node runners were raising their revenue share/costs. In fact, once LeanPocket was avaliable to the public, we were helping all node runners and even major node providers to quickly adopt this feature. Additionally, it is important to note that we did not receive any compensation from any organization in exchange for early access or private implementations of Lean Pocket. The intention was always to keep it transparent, open source and later be compensated by the DAO for our work. We hope that the DAO can realize this lost opportunity cost when considering the reimbursement ask.

Why was lean pocket closed source initially?

The core team advised we kept it closed source until it was reviewed thoroughly to ensure that the contribution was safe and to minimize any protocol disruptions, Post for reference

After multiple v0 core contributions and code review calls and revisions(led by Luis - [ex] PNI CTO himself), LP was made available to the public as soon as it was deemed safe enough for the entire ecosystem to use.

A Note from the team:

Thank you all for supporting PoktFund throughout this incredible journey. We hope that you are to understand and support us through this DAO ask.

This is only the start of something truly magnificent. We have grown from just a small company to something that becomes more sustainable and lucrative if we are able to get our reimbursement.

Title HC
Engineering 6
PM 1
UX Designer 1
Sales 1
On call / as needed basis engs / advisors 3

Above is our active headcount (actively contributing). We have even more products and plans that we’re going to be discussing and executing on. We’ve been in close contact with multiple organizations in the ecosystem on collaboration ideas, hell - we may even be doing more protocol work as V1 matures. We’ve stepped into advisory for node running, protocol advice, infrastructure optimizations, and now even hopping into calls with PNF to discuss our roadmap for this year. While we are looking for reimbursement in this proposal, please keep in mind this undoubtedly helps motivate our organization and incentizes us to focus on driving value to the network and being active participants in the ecosystem.


Lean Pocket

Initial Research ( design doc, validator design doc, github proposal)

Proof of Concept (Infracon showcase)

Code Implementation with Code Review (Pull request)

Unit tests / integration tests (Pull request)

Community support on Discord/Telegram/DM

Collaborating and reviewing LP documentation with PNI

Release (0.9.2+)

Chocolate Rain

Tested on the local net

Proof of concept and remediation docs sent to core team

Crisis averted in 0.9.0

Bug bounty reimbursement research (forum post)


Copyright and related rights waived via CC0.


I think there is not much to argue here. The impact of LeanPOKT is undeniable, without it the network cost would be impossible to sustain. I think that the amount asked is very reasonable.

I only have one question, as I thought that TH was a central contributor of LeanPOKT.
Are they going to ask a similar amount for their work? or this proposal is the largest amount to be asked to the DAO? (maybe someone from TH can clarify this point).

P.S.: GeoMesh actually started non-lean (early closed proof of concept), but it would have sucked that way lol


Seems like a well rounded proposal on first pass. Two questions:

  • How much of the ask is for LeanPokt and how much for Chocolate Rain?

  • Of the work performed to bring LeanPokt to production, what percentage was PoktFund, and what percentage was Thunderhead?

I think having these values broken out will help the DAO evaluate the value proposition, especially in regard to @RawthiL 's question.


I think we’ll leave it to the DAO to decide what central contributor means. However, we stand by that this was a collaboration between two teams in a very unique time where there was no room for two light clients being developed separately.

I think our organization should refrain from providing a breakdown of this as it is likely to be biased/subjective. So instead, we try to frame the proposal to provide the evidence and details on what we worked on and the rationale for the costs incurred for PoktFund only. In terms of the responsibilities of LP, we were the primary owners of designing and implementing LeanPocket, and below are some artifacts of what was created primarily by us:

Initial Research (design doc, validator design doc, github proposal)

Proof of Concept (Infracon showcase)

Code Implementation with Code Review (Pull request)

Unit tests / integration tests (Pull request)

Community support on Discord/Telegram/DM

Rebasing and supporting chain halts for noncustodial lean pocket upgrades

Collaborating and reviewing LP documentation with PNI

Now, this is not to say that TH was not part of the process or was not a contributor to LeanPocket, They did help with testing it on their fleet, providing feedback on how to improve it, helping with Q/A testing, comarketing, etc. We don’t want to provide false details to the DAO - and we would say that both entities are pretty generally aligned on how the work was split. However, we don’t want to speak for them for what they did and how much they want for it - so take what we say with a grain of salt on what they actually worked on as there may be missing details there. Given that the DAO is not likely to grant based purely off impact (i.e $2m), this was one of the reasons why we decided to post a split proposal. Both organizations are in different spots and as a result, incurred different types of costs when creating LeanPocket.

Yes, this is a great callout - not sure how we missed this. To be honest, we combined them as two as we think there is a value-added in showing contributions that were actionable from multiple lenses for a comprehensive grant justification. We did an analysis of the fair market value to ensure that we are abiding by a range that is reasonable and has data backing it so that way the DAO is not held, hostage. A crit vulnerability bug bounty payout based on our research showed that the median ranged from $100k to $1m.

If we are breaking it down loosely, we are targeting around half of the minimum payout of a crit vulnerability (833333 POKT) and the rest attributed to LP. But once again, the security disclosure vulnerability is something new to the DAO, and so others may see that contribution as worth more or less.


Awesome, thanks! This is a solid breakdown.

1 Like

Solid pre-proposal start. LeanPOKT development is highly deserving and I’m glad this is moving forward!

What % of this proposal is to cover the lost opportunity vs reimbursement for the contribution itself?

I’ve been a stickler with structuring modeling of proposals, so forgive me if any of this is repeat of past comments :sweat_smile:

I don’t think the DAO can reward project’s based on their perceived market value (like the original proposal) or in this case the perceived market value that was lost (aka lost opportunity). I just don’t think that is a way the DAO should measure proposals. I don’t see that scaling, which is why I feel it’s important to measure things out.

While PoktFund did give much to the community by developing PoktFund and help other support it (which should be reimbursed), PoktFund did use the knowledge gained from that work to create your own version of geo-mesh client in the summer which never was opened sourced. PoktFund used that work on v0 to beat out many providers and become is the top node provider today.

POKTScan realized how top performing providers were doing it in the fall and opened it up to the whole community, despite the fact they could have kept it closed source to improve their own market share. Not sure then how we try to measure their lost opportunity if they were to submit a proposal.

To me, that is how open-source at work. LeanPokt dramatically reduced the cost of the network, helping the market no doubt… but at the end of the day, that work (which should be reimbursed by the DAO) lead to PoktFund being the biggest provider in the POKT ecosystem.

I may be shooting myself in the foot here as I am planning on doing a proposal for a new product we are launching called Community Chains and I’m limiting how I could eventually structure that proposal by being a stickler on structuring everything in measurable ways.

My suggestion would be to not have this proposal’s value be measured through lost opportunity.


Hi Shane, thank you so much for supporting LeanPOKT to start off with.

Yes, we agree with you on this actually. If we were to do perceived market value only (lost opportunity) then the asking amount would be much more. However, we are only asking the DAO to consider it as a factor. We do not have a precise percentage, but we know that node runners can make upwards roughly $100k-$300k/month USD during this time frame, especially those who had their own version of the “light client” at the time.

We were only able to operate a geo mesh client for less than ~3 months (roughly, can’t say for sure) and we were not even running it at a large scale as large providers today (2 regions initially). It wasn’t ready for production use either. Whenever we were asked questions on the protocol specifics and how to run a testnet by Poktscan, we helped. (very briefly! once again, credit to Jorge and everyone on the team for this invention). We even pointed out a memory bug that they could incorporate into Geomesh, which they did. Our team has always been open to helping and growing the ecosystem. We were actually considering releasing it OS open-source later down the road once it was scaled and tested, but Poktscan beat us to it and huge props to them.

I think in general we understand your point here, but building a business from literally 0 to #1 took a lot more work than providing great QoS using geomesh. We had to build a website, we brought in a fantastic relationship-building account manager, created fantastic competitive deals, and business development, we had to build our infrastructure and own node running tooling such as Nodies Monitoring which we also have an open source for everyone to use. It is a fact that we are generating revenue and ofc, won’t deny that, but we can’t fully attribute it to LP. We gave everyone adequate time to adopt LP and decrease their costs to be competitive. We are not asking for reimbursement for node running, but rather consider it as a factor when we were focused to bring this out to the masses for everyone instead of aiming for privatization as some other providers did.


Hi everyone,

Just want to provide some clarifying points. After we proposed the idea of partnering up on this effort with PoktFund, we agreed to go 50/50 on any potential proceeds. We would break all doors down, build this together as if we were one team, and submit a funding proposal. A few weeks after submitting the original proposal, we offered to renegotiate the split in their favor prior to the next proposal, but PoktFund wanted to keep it at 50/50.

Now that we delivered LeanPocket to the network and are looking for retroactive funding, PoktFund told us they would submit their own proposal, reneging on our original agreement to share proceeds.

To us, this represents a lack of character and integrity that hurts us deeply. That being said, there is nothing we can do at this point, and will move forward amicably since we both put tremendous efforts into this project and both deserve to be rewarded.

Inferences were made that don’t align with reality.

No longer the case because PoktFund reneged.

We are. In no way shape or form could Lean Pocket have been released without this partnership. We both brought unique skillsets to the table .

It is hard to discern an exact percentage, especially in a public forum.

This is a non-exhaustive list of our contributions. (I was not expecting this post this morning)

  • Came up with the original idea (Posted to the forum + several conversations with core devs in February)
  • Presented our original work at InfraCon and met with all of the core devs in order to build a plan of collaboration
  • Several conversations with Pocket execs to get them to support the effort.
  • Conducted large scale testing on our fleet and latency/performance measurement and analysis.
  • QA testing and creation of all the test scenarios
  • Hosted AmAs to educate the community and spread awareness. [1, 2]
  • Lean Pocket announcement and marketing [1, 2]
  • Infographics and explainers [1, 2]
  • Support and answering everyone’s questions/concerns [1,2,3]

This was a team effort. Its impossible to exactly delineate each of our contributions since we built this together.

I never anticipated things to turn out this way . We initiated and spent an inordinate amount of time on this effort and were pivotal in the process. We will submit our own proposal seeking retroactive funding.


I think you guys are selling yourselves short. We are talking about arguably the most influential piece of update for Pocket in 2022. Without it, the network might’ve gone into ruin due to the low token prices and high costs in running the regular client. I will support this proposal as-is, though I would personally like to see you compensated more.


Troubling Divisiveness

I find this response deeply troubling. Not because TH is going to ask for reimbursement separately. It’s the divisiveness that it exudes. To be clear, however, I am not saying that this person or that person is in the wrong.

If Pocket is to succeed, let alone survive, we need to pool together and cooperate. There has been discussion around encouraging node runners and developers to share their work for the good of the network and all its participants, rather than work at cross-purposes. Dermot has spoken recently in the Forum of the need to treat each other with respect and to engage with civility.

DAO Mediation Mechanism

This highlights the need for a DAO mechanism to resolve such disputes rather than let them fester and spill out into the open. A third party could easily have helped to settle this disagreement behind the scenes.

I would be happy to collaborate on a proposal for the creation of such a mechanism. This will strengthen our community and the Pocket Network.


We don’t want to derail this thread on ownership of lean pocket efforts. This should not be a discussion of any previous negotiations between private companies (we won’t go into this) but rather the work completed by PoktFund and the reimbursement for said work. At the end of the day, other organizations who contributed in any way, shape, or form can make their own proposal and justify an ask to the DAO for their effort. We are NOT separating this proposal to say we are the only ones who contributed or should be reimbursed for efforts towards Lean Pocket. This particular proposal serves to purpose the reimbursement for PoktFund’s efforts in Lean Pocket and Chocolate Rain.

To clarify what we’ve done in terms of Lean Pocket, it is indisputable that we did most if not all of the work on development, unit testing, supporting upgrades, and review processes (refactors) with the core team (see commit history on the pull requests). ThunderHead made the first public post about the unnecessary 1:1 relationship between nodes but as per Blade’s post here , this had been on our radar for some time as well. It was also not the first time we heard of the idea or a unique issue prior to the post (this was also on core team’s radar and was briefly discussed with noderunners)

The crux of it is that we found a large inefficiency where V0 core bandwidth development was limited and we had the protocol expertise to fix the problem in a timely manner. We collaborated with ThunderHead as to not duplicate work thus they assisted primarily in testing on a large scale production fleet, co-marketing, and navigating the core team discussions to get them aligned. They will make their own proposal for reimbursement on those items and anything else that I missed. The work done on the designs and source code is primarily what we are seeking reimbursement for when it comes to Lean Pocket. As for community support/marketing/aligning core team, we put in significant effort for this too but do not claim it as a solo effort.

There have been attacks on our character and to be frank we aren’t interested in any such arbitration. It is clear cut what work we did as it is engrained in commit history. This is about being rewarded for the work completed and recognizing the loss opportunities we endured as a company (delaying our node operator business, no privatization) to get this out for the greater good. We hope the DAO recognizes our efforts and acts accordingly.


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.


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


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.


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.


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.


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:


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.


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.