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

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.

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

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

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:

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/ 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