# Who Evaluates Polkadot Treasury Proposals? Transparency, Technical Accuracy, and Supporting Real Builders

**URL:** <https://forum.polkadot.network/t/who-evaluates-polkadot-treasury-proposals-transparency-technical-accuracy-and-supporting-real-builders/19141>\
**Category:** Governance\
**Created:** [October 27, 2026, 6:36am UTC](https://forum.polkadot.network/t/who-evaluates-polkadot-treasury-proposals-transparency-technical-accuracy-and-supporting-real-builders/19141 "2026-10-27T06:36:22Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ahjxcrz](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ahjxcrz/32/4111_2.png) [@ahjxcrz](https://forum.polkadot.network/u/ahjxcrz)\
**Post date:** [October 27, 2026, 6:36am UTC](https://forum.polkadot.network/t/who-evaluates-polkadot-treasury-proposals-transparency-technical-accuracy-and-supporting-real-builders/19141/1 "2026-10-27T06:36:22Z")

</div>

Hi Polkadot community,

I’d like to open a discussion about how Treasury proposals are evaluated, particularly when assessments are presented as formal technical or systemic risk audits.

Our recent proposal, **Referendum #1956 — ComputeFlux Pilot** , received a comment titled “SYSTEMIC RISK AUDIT REPORT,” recommending a hard NAY vote.

We fully respect everyone’s right to question Treasury spending, challenge proposals, and vote according to their own judgment.

However, several claims in this assessment appear to overlook important facts about ComputeFlux, including our open-source infrastructure, Polkadot PVM smart contracts, existing product, and commercial business model.

Rather than simply responding to one assessment, we’d like to raise a broader discussion about transparency, technical accuracy, and how the ecosystem evaluates teams that are actively building.

## 1. Who Is Behind These Treasury Audit Reports?

We would genuinely like to understand:

- Who authors or operates these assessments?

- Are they affiliated with an established Treasury evaluation organization, or are they independent community reviewers?

- What technical methodology is used?

- Do reviewers examine publicly available source code and deployed infrastructure before issuing technical conclusions?

- Is there a process for correcting factual inaccuracies?

When a report uses terms such as “CRITICAL INVARIANT VIOLATION” and “SYSTEMIC RISK,” it is reasonable to ask what evidence supports those conclusions.

We welcome independent evaluations and critical feedback. But transparency, accountability, and technical accuracy should be fundamental to the process.

 ![Screenshot 2026-10-26 at 11.32.59 PM](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/4/47fd83463322bb602a12b7fa71e2468a7fae1a4f.png)

> **[ComputeFlux: Polkadot AI Adoption & dotUSD Utility Pilot](https://polkadot.subsquare.io/referenda/1956#11)**
>
> Making AI Computing a Real-World Use Case for Pol...

## 2. ComputeFlux Is Not Simply an Off-Chain API Wrapper

The assessment describes ComputeFlux as an off-chain software wrapper lacking compute provenance verification.

However, our decentralized infrastructure and Polkadot smart contract implementations are publicly available.

**Repository 1 — TEE-Based Decentralized Compute Infrastructure**

> **[GitHub - computeflux/tee-node](https://github.com/computeflux/tee-node)**
>
> Contribute to computeflux/tee-node development by creating an account on GitHub.

This repository includes components and designs for:

- CometBFT-based blockchain consensus

- Trusted Execution Environment (TEE) attestation

- Distributed key management

- Decentralized node coordination

- Verifiable compute infrastructure

**Repository 2 — Polkadot PVM Smart Contracts**

> **[GitHub - computeflux/revive-contract](https://github.com/computeflux/revive-contract)**
>
> Contribute to computeflux/revive-contract development by creating an account on GitHub.

This repository includes PolkaVM / pallet-revive smart contract implementations for:

- Compute subnet management

- Worker registration

- Staking and slashing mechanisms

- TEE validator management

- Token and payment-related functionality

These are not simply API forwarding scripts.

They represent substantial engineering work toward decentralized compute infrastructure integrated with blockchain systems.

Of course, open-source code alone does not establish the deployment or verification status of every component. We welcome technical questions about which mechanisms are operational today and which are still under development.

However, a serious technical assessment should examine the actual architecture before characterizing the entire project as an unverified software wrapper.

The report also references the absence of Model Context Protocol (MCP). MCP is an interoperability protocol for AI applications, tools, and data sources. It is not a hardware attestation or compute provenance standard.

**We welcome code-level technical criticism. Our repositories are public, and anyone can review them.**

## 3. We Built ComputeFlux Entirely With Our Own Resources

This is perhaps the most important point we want to clarify.

**ComputeFlux has received $0 in funding from the Polkadot Treasury.**

Our team has invested its own money, engineering effort, time, and computing infrastructure to develop and launch the product.

We did not wait for Treasury funding to start building.

We already have a working platform, deployed services, and infrastructure available to users.

Our business model is straightforward: provide AI computing services to developers, businesses, and AI agents, generating revenue through paid compute usage.

Our long-term sustainability depends on real paying customers and recurring usage, not continuous Treasury subsidies.

**We need users, not a Treasury-dependent business model.**

The purpose of our proposed pilot is to onboard Polkadot developers, integrate practical dotUSD payments, and create measurable ecosystem adoption.

A customer acquisition budget is not the same as a subsidy-dependent business model.

## 4. Our Proposal Already Includes Measurable Adoption Targets

The assessment claims our operational model relies entirely on subsidized credits without user conversion metrics.

However, Referendum #1956 already includes measurable adoption objectives, including:

- 500 new registered users

- 100 active AI users

- 50 API developers

- Developer integrations and ecosystem collaborations

- Tracking genuine dotUSD payments separately from promotional credits

- Reporting usage and repeat payment activity

We welcome feedback on these targets and are open to strengthening reporting and accountability.

But evaluations should accurately represent what is already documented in the proposal.

**Referendum #1956:**

> **[Polkassembly - Referendum #1956](https://polkadot.polkassembly.network/referenda/1956)**
>
> ComputeFlux: Polkadot AI Adoption & dotUSD Utility Pilot

## 5. What Kind of Ecosystem Are We Trying to Build?

This discussion goes beyond ComputeFlux.

Building real products in Web3 is difficult.

Teams invest their own capital, time, and engineering resources, often without knowing whether their products will find users.

We chose to build first.

We developed our infrastructure, launched our product, and open-sourced significant technical components. Now we’re trying to attract real developers and paying customers.

We believe Polkadot has the potential to support useful applications that create genuine demand for its infrastructure, assets, and payment ecosystem.

We are not asking for unquestioned support or special treatment.

We are asking for technical evaluations that are transparent, accurate, and grounded in evidence.

**If a team builds with its own resources, ships a working product, and open-sources its infrastructure, how should the ecosystem evaluate and encourage that effort?**

And when an assessment contains questionable technical claims, what mechanism should exist to challenge or correct them?

We would genuinely appreciate perspectives from community members, delegates, Treasury reviewers, and other builders.

## 6. $1,000 in Free AI Credits — Funded Entirely by Our Team

We believe the best way to evaluate a product is to actually use it.

Rather than simply debating whether ComputeFlux delivers real value, we’d like to invite Polkadot community members to try it themselves.

**$0 Treasury funding received. $1,000 more committed from our own team to onboard real Polkadot users.**

We’re offering **$10 in free ComputeFlux AI credits to each of the first 100 eligible Polkadot community members** , funded entirely from our own resources.

### How to Participate

1. Visit [https://test.computeflux.ai/](https://test.computeflux.ai/) and register an account using your wallet or email.

2. On the top right, copy your computeflux address

3. Reply to this forum thread with your registered public wallet address.

4. The first 100 eligible, verified participants will each receive $10 in free AI compute credits.

**Important details:**

- Total promotional budget: $1,000, entirely funded by the ComputeFlux team.

- One reward per real participant, subject to eligibility verification.

- Multiple wallets or accounts controlled by the same person do not qualify for additional rewards.

- Credits are for AI computing services only and cannot be withdrawn, transferred, or exchanged for cash or tokens.

- Share only your public wallet address. Never share private keys or recovery phrases.

- No vote, endorsement, positive review, or support for our referendum is required.

- Everyone is welcome, including those who disagree with our proposal.

We welcome honest feedback, criticism, bug reports, and suggestions.

Our goal is not simply to distribute credits. We want people to experience the product, build applications, and potentially become long-term users.

**We built the infrastructure. We launched the product. Now we want real users.**

* * *

We came to Polkadot because we believe in the potential of its ecosystem.

We have invested our own resources, taken the engineering risks, and delivered a working product.

We welcome scrutiny. We welcome competition. And we welcome constructive criticism.

But evaluations should be based on actual evidence, not assumptions.

**Constructive criticism makes an ecosystem stronger. Fair evaluation matters just as much.**

Let’s build real utility together.

— **ComputeFlux Team**

> **[ComputeFlux — Decentralized TEE Compute Network](https://computeflux.ai)**
>
> Private RPC relay & anonymous AI gateway. 100% TEE encrypted, no KYC, instant crypto settlement. Multi-chain token forwarding across 10+ blockchains.

---

<div class="post-metadata">

**Author:** ![thewhiterabbitM](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/thewhiterabbitm/32/11298_2.png) [@thewhiterabbitM](https://forum.polkadot.network/u/thewhiterabbitM)\
**Post date:** [October 27, 2026, 8:41am UTC](https://forum.polkadot.network/t/who-evaluates-polkadot-treasury-proposals-transparency-technical-accuracy-and-supporting-real-builders/19141/2 "2026-10-27T08:41:54Z")

</div>

I think this discussion raises a much bigger issue than the technical evaluation of a single Treasury proposal. It raises the question of whether Polkadot OpenGov is still functioning as a genuinely open governance system.

There was a time when a much broader community actively evaluated Treasury proposals. Was that process perfect? Absolutely not. Mistakes were made, evaluations were sometimes inadequate, and there was plenty of room for improvement. But there was also a much wider distribution of responsibility, expertise, and independent scrutiny.

Then came the DV era, of which I was part. Did we make mistakes? Absolutely. No governance model is immune to bad judgments, conflicts of interest, or inefficiencies. The point is not to romanticize the past, but to acknowledge that these shortcomings should have led us to improve the system, not progressively concentrate decision-making power.

**Today, the problem is that meaningful evaluation appears to have become concentrated in the hands of one or two entities.** When this happens, the broader community gradually stops investing time and effort in analyzing proposals because it knows that the real assessment has already been made elsewhere.

This creates a vicious cycle: fewer independent reviewers become involved, less scrutiny takes place, and the remaining gatekeepers gain even more influence over what gets funded.

There is an additional concern that deserves a transparent answer: to what extent are the same entities that influence funding decisions also involved in commissioning, shaping, or facilitating proposals submitted by organizations such as the Polkadot Community Foundation (PCF)?

I am not claiming that a conflict of interest has been proven in every case. I am saying that if such relationships exist, they must be disclosed and independently scrutinized. Otherwise, token holders may be asked to approve proposals through a process that looks decentralized and democratic on the surface, while the substantive decisions have already been made by a small group behind the scenes.

A vote does not automatically make a process meaningfully decentralized. Nor does the fact that token holders can approve or reject a proposal guarantee that they have access to independent analysis, balanced information, or genuine alternatives.

**This is where I believe OpenGov is experiencing a structural failure.**

The steward was supposed to help the ecosystem function, coordinate processes, and enable better decision-making. A steward is not supposed to become the owner of the system, the ultimate gatekeeper of funding, or an authority whose judgment effectively substitutes for the collective intelligence of the community.

Polkadot is supposed to be Web3. No individual or organization should be able to behave as though they own its governance, its Treasury, or the ecosystem’s future.

And this is not just a question of fairness toward ComputeFlux, or whether this particular proposal deserves a YES or a NAY. The same standards must apply to every team, every foundation, every service provider, and every proposal.

If independent community members no longer feel that their analysis matters, if reviewers cannot meaningfully challenge the dominant assessment, and if funding decisions are effectively controlled by a handful of gatekeepers, why should experienced builders and independent contributors continue investing their time in governance?

**They won’t. Not seriously, and not for long.**

That is the real cost of excessive centralization: not simply a few questionable funding decisions, but the gradual disengagement of the very people who could make the governance system stronger.

We need more independent evaluators, transparent evaluation criteria, disclosure of potential conflicts of interest, a clear process for challenging factual errors, and accountability for those who exercise disproportionate influence over funding decisions.

We also need to distinguish between legitimate criticism of a proposal and the concentration of power to determine which proposals receive serious consideration in the first place.

The old system made mistakes. The DV system made mistakes. The current system will make mistakes too. The question is whether we learn from them or continue concentrating power while calling the result decentralized governance.

**OpenGov cannot be genuinely open if meaningful scrutiny is outsourced to a handful of gatekeepers and everyone else is expected to rubber-stamp the outcome.**

If the steward continues to behave as though it were the absolute authority over Polkadot, rather than a steward accountable to the ecosystem, serious community participation will continue to decline.

We should not be asking only who evaluates Treasury proposals.

We should be asking who evaluates the evaluators, who holds the gatekeepers accountable, and what mechanisms exist when those entrusted with stewardship begin acting as owners.

Because if those questions have no meaningful answers, then OpenGov is not simply underperforming.

It is running in a governance deadlock of its own making.
