PixelProof, and the Cost of a Careless Aye

[hantoniu-codeberg]

The Polkadot treasury funded $225,000 for a privacy-focused photo storage application. The application stores unencrypted personal photos on IPFS — a public network where anyone with a content identifier can retrieve the data from any gateway in the world. The company that built it shut down five weeks ago.

I am primarily active on Kusama governance. Each network has its own stakeholders and delegates, but the communities overlap significantly and the governance practices on one inevitably influence the other. I went through this case in detail because I think the pattern it reveals is worth examining.

What was promised

Referendum 1631 requested $575,000 to build PixelProof — a “decentralized Google Photos” on Polkadot. It was rejected at 99.7% Nay. A revised Referendum 1670 reduced the ask to $225,000 for a lean MVP and passed with 63% approval in December 2024.

The revised proposal explicitly promised client-side encryption. When a commenter asked how end-to-end encryption would work, the proposer responded with a detailed commitment from their CTO: “all images will be fully client-side encrypted,” with encryption keys “derived from the user’s wallet and passkey,” ensuring “only the user can access their stored images.”

What was delivered

PixelProof’s source code is public on GitHub — 23 commits, zero stars, zero forks, created October 2025 (ten months after funding). As of February 2026, pixelproof.com shows a “Coming Soon” landing page.

I read the upload pipeline end to end. The UI passes raw files to a handler, which wraps them in a FormData and POSTs to the server. The server converts each file to a buffer and sends it directly to the Apillon SDK for IPFS storage. At no point is any encryption applied. I searched the entire codebase for encrypt, cipher, AES, chacha, E2E, end-to-end — zero matches in application source code. The proposal promised client-side encryption. The code uploads raw bytes to IPFS.

This matters because IPFS is public by default. CIDs are announced to the distributed hash table publicly, and any gateway can resolve them. PixelProof includes a smart contract on Moonbeam that manages access lists — but this only controls what the web application displays to logged-in users. It cannot prevent direct access via CID. Without encryption, this access control is cosmetic. The photos are public data with a UI layer on top — arguably less private than Google Photos, which at least requires authentication at the infrastructure level.

The application’s entire storage backend depends on the Apillon SDK. Every file operation — uploads, bucket management, IPFS pinning — goes through Apillon’s infrastructure. In mid-2025, Apillon announced it was winding down, citing market conditions and Polkadot tech stack fragmentation. The platform ceased operations on January 1, 2026. The $225,000 investment is effectively stranded.

What already existed

The problem space PixelProof set out to address has mature, open-source solutions:

	PixelProof	Ente	Immich
End-to-end encryption	Promised, not implemented	Yes — encrypts on device before upload	Optional
Security audits	None	3 independent firms (Cure53, Symbolic Software, Fallible)	Open source (no formal audit)
Self-hostable	Depends on Apillon (shut down)	Yes (S3-compatible backend)	Yes
Mobile apps	None	iOS, Android, Web, Desktop	iOS, Android, Web
AI search	Excluded from MVP	Yes	Yes (CLIP, facial recognition)
Production scale	“Coming Soon”	200M+ photos stored	90,000+ GitHub stars
Cost to treasury	$225,000	$0	$0

Ente’s architecture is worth noting specifically. Its S3-compatible storage backend means it can work with any S3-compatible provider — including, potentially, Polkadot-native storage solutions like PolkaStorage or StorageHub. The path to privacy-preserving photo storage on Polkadot was never about building a new application from scratch. It was about filling the infrastructure gap that existing applications already need.

How did this pass?

Referendum 1670 had 204 voters. The contrast between the two sides is worth looking at.

On the Nay side, Permanence DAO conducted a ten-member internal review — zero ayes, four nays, two abstains — and explicitly flagged the missing competitive analysis. JAM DAO flagged the budget as excessive for an MVP. One commenter who initially voted Nay called the project “a demonstration of Apillon SDK integration rather than a solution to an ecosystem-wide need” — before flipping to Aye after a phone call with the team, citing that they seemed “genuinely committed to building something meaningful.”

On the Aye side, the public reasoning that was visible did not engage with the technical substance. No commenter checked whether the problem was already solved. The one voter who asked about encryption received a detailed commitment from the proposer — and voted Aye on a promise that was never delivered.

Here’s where I land

We spend considerable energy in this ecosystem debating the behavior of those who vote Nay. But the asymmetry is worth stating plainly: a wrongly rejected proposal can return with better arguments and a revised scope — the ecosystem loses time, not capital. A carelessly approved proposal spends real money. In this case, $225,000 on unencrypted photos on a public network, built on infrastructure that no longer exists, solving a problem that open-source communities solved years ago for free. The voters who said No were right.

That is not a comfortable observation, but it’s an important one. We should be at least as rigorous with our Ayes as we are critical of our Nays.

I opened a thread on Kusama Shield v2 asking substantive questions — about relay models, privacy guarantees, audit timelines, swap mechanism design. The team responded in detail. You could follow the exchange and come away with a clear understanding of what was being built, what the limitations were, and where the roadmap was headed. That is how it should work.

PixelProof passed without any of that scrutiny. The encryption question got a detailed answer that turned out to be hollow. Nobody asked what already existed. The dependency on a single company’s infrastructure went unexamined.

The ecosystem is in a transition period. Communication from W3F and Parity has been sparse, but significant work is underway — JAM, native storage infrastructure, runtime improvements. The technical foundation for the next phase is being built. When it arrives, the treasury will be asked to fund applications on top of it. We should be ready to evaluate those proposals better than we evaluated this one.

The questions aren’t complicated: Does a privacy claim come with a credible technical specification? What already exists in this space? Does it make financial sense against free, open-source alternatives? What happens if the underlying provider disappears?

For my part, I’m focused on Kusama. I’ve been asking for clarity on whether Kusama is meant to chart its own course or follow Polkadot’s lead — that question is still open, and the answer shapes where community effort is best spent. Until then, I’ll keep building in the open and pushing for the kind of scrutiny that makes treasury funding worth defending.

[jslusser]

Thanks for taking the time to document this so thoroughly. I voted Aye on Ref 1670, and your review is an uncomfortable but important reminder of the responsibility that comes with that vote.

I agree with your core point: we should apply at least the same rigor to our Ayes as we do to our Nays. A rejected proposal can come back stronger; a carelessly approved one permanently spends real capital (with the caveat that milestones can help). In this case, the gap between what was promised and what was delivered - especially around encryption and infrastructure dependencies - is hard to ignore.

I’m active in both Polkadot and Kusama governance, and I also appreciate the contrast you draw with more substantive, technically grounded proposal discussions. Clear specs, honest limitations, awareness of existing solutions, and credible contingency planning should be baseline expectations going forward.

This post is a valuable contribution, not as hindsight blame, but as a concrete framework for how we evaluate future treasury asks - especially as the ecosystem enters its next technical phase. Appreciate you putting this in the open.

[Onepebble]

As a member of Permanence DAO this is a bittersweet moemnt for us as a DAO, thanks for doing the post.
I agree the processes must change, but the deeper urgent issue is the brain drain from our ecosystem… including from my company. Too many funded efforts lack market fit. Even programs meant to drive awareness and uptake have failed because curators and staff lacked the necessary experience. That failure wastes treasury funds and, worse, wastes people’s time and talent.
There is a persistent belief among some that foundations and core teams should operate like product companies. Parity and W3F can build technology; whether they can reliably ship and market user-facing products at scale is a different question. Incubators were funded, yet silence followed; investors and family offices seem uncertain about where to place bets. The result is a cycle of money going to initiatives that do not produce sustainable adoption.
We are a three-person team of proven C‑level operators committed to building around this tech with a user centered approach. Launching a two sided product requires focused resources and highly targeted marketing. Many of the initiatives that would create real social value are not attractive to traditional VC because they do not promise hyperscale financial returns, even though much of the current crypto portfolio is underperforming.
What we need now are bounties and funding processes that actually work: curators who are true experts, accountable to clear success metrics, and who track outcomes after funding is disbursed. Reputation and proof-of-performance matter, and systems like PoPersonhood can help. Governance should enable proposers and voters to support each other, not fight. We can borrow corporate practices around accountability and apply them in a decentralized way so decisions are informed and fair, not driven by gatekeeping or short term gain.
The culture problem is real: too much of our community behaves like gamblers seeking quick alpha instead of builders with long-term vision. That mindset allows vote whipping, narrative capture, and repeated misallocation of funds. We need more lenses, more domain expertise, and stronger mission alignment in how we fund and steward projects.
We have a clear vision and a product ready to ship. We will work with parity or W3F where it makes sense, and we will not wait for perfect conditions… in practice we may launch initially as a web2 experience to prove market fit and user value. Demonstrable traction will make it easier to integrate native primitives later and to convince funders and the broader community that investment is justified.
If the goal is to stop the bleeding and build sustainable adoption, we must prioritize expertise, mission driven funding, measurable outcomes, and processes that protect contributors rather than drive them away.

[w3nerick]

I think the situation is looking grim. Just looking at the landscape of the REVIVE update, there are no people or developers interested in building on Polkadot. Projects like Centrifuge, Moonwell, PhalaNetwork, and others that operate outside the Polkadot chain are finding success on Ethereum, with greater liquidity and higher user adoption. I don’t believe the W3F will manage to have a significant impact on bringing users to the network, the best talent is leaving Polkadot.

When a particular community is destroyed, it is actually a part of all of us that is destroyed. - Dalai Lama XIV

[hantoniu-codeberg]

The frustration in this thread is legitimate. Real money was spent on work that didn’t deliver. Talent has left. None of that is comfortable to sit with.

But there are only two honest responses. Leave, and put your energy somewhere you believe in more. Or stay, and build the part that was missing.

This post was about one specific failure mode: proposals that pass without serious scrutiny. That’s fixable. It doesn’t require new infrastructure or foundation support. It requires voters who check the code, ask what already exists, and hold proposers to what they promised. @jslusser’s response here is proof that shift is already happening — an Aye voter looking back and saying “we should have been more rigorous.” That’s the culture change.

@Onepebble, Permanence DAO’s structured review process — ten-member internal reviews with published vote counts — is exactly the kind of rigor that was missing on the Aye side of this referendum. Your point about curator accountability and post-funding outcome tracking deserves its own thread. That’s a concrete mechanism the ecosystem can implement.

@w3nerick, the talent loss is real. But talent follows opportunity, and opportunity follows credibility. Every proposal that passes scrutiny and delivers builds that credibility back. Every one that doesn’t erodes it further.

The infrastructure for the next phase is being built — smart contracts went live on Polkadot Hub two weeks ago, and JAM has 14 teams building implementations. Whether the governance keeps pace is up to us.