Copy pasting, as this and many comments from Polkassembly are not showing here:

@polkaworld Thank you for the analysis but that is a simplistic approach. We are not a few friends splitting the cost among ourselves. As a business, on top of paying salaries we have to cover other supporting personnel, health and social security contributions, sick leaves, vacations, national holidays, training, replacements and taxes. You can’t operate a business without margin, otherwise you won’t have one for long.

People don’t only buy things because they are cheap, they buy things because the value they get in return is bigger than the amount spent.

@12mP4sjCfKbDyMRAEyLpkeHeoYtS5USY4x34n9NMwQrcEyoh Thank you for the analysis but that is a simplistic approach. We are not a few friends splitting the cost among ourselves. As a business, on top of paying salaries we have to cover other supporting personnel, health and social security contributions, sick leaves, vacations, national holidays, training, replacements and taxes. You can’t operate a business without margin, otherwise you won’t have one for long.

People don’t only buy things because they are cheap, they buy things because the value they get in return is bigger than the amount spent.

Copy pasting, as this and many comments from Polkassembly are not showing here: @polkaworld Thank you for engaging in this process.

"we believe that the public salary data we referenced already includes the types of costs you mentioned — because most Web3 professionals are employed within companies, and these statistics inherently reflect the full employment cost, including social benefits and leave."

This is not true. Employee salary data does not contain employer costs and other business costs, it is simply the gross amount payed to the individual. I understand that things might work differently in other regions of the world thus resulting in this confusion.

Here is the example for Sweden which you used above, using your 150k average. People also get about 10% of the year in vacations, 5% in national holidays, 0-10% in sick days, these are all costs. On top of this we have to pay salaries of operating staff, train people for replacements and taxes.

@12mP4sjCfKbDyMRAEyLpkeHeoYtS5USY4x34n9NMwQrcEyoh Thank you for engaging in this process.

"we believe that the public salary data we referenced already includes the types of costs you mentioned — because most Web3 professionals are employed within companies, and these statistics inherently reflect the full employment cost, including social benefits and leave."

This is not true. Employee salary data does not contain employer costs and other business costs, it is simply the gross amount payed to the individual. I understand that things might work differently in other regions of the world thus resulting in this confusion.

Here is the example for Sweden which you used above, using your 150k average. People also get about 10% of the year in vacations, 5% in national holidays, 0-10% in sick days, these are all costs. On top of this we have to pay salaries of operating staff, train people for replacements and taxes.

Thank you for your reply, and we appreciate your transparency in explaining the broader cost structure involved in running a business — we understand that operating a company involves more than just paying salaries. It also includes supporting personnel, health and social security contributions, sick leave, vacations, national holidays, training, replacements, and taxes. We fully acknowledge this reality and respect the complexity behind your operations.

However, our concern is not about undervaluing your work or expecting “cheap labor.” Rather, it’s about ensuring that any project funded by the Polkadot Treasury maintains a compensation structure that is reasonable and well-justified, especially when viewed in the context of local market benchmarks and clear role-based differentiation.

We understand that running a company involves a margin and overhead. But it would greatly help if a more detailed breakdown could be provided to justify the FTE cost of $25,000 per month per team member. Is this the average cost across the team? Does it reflect different roles such as engineering, project management, or administrative support? At present, the flat-rate structure raises concerns about the lack of performance-based or responsibility-based distinctions.

Moreover, we believe that the public salary data we referenced already includes the types of costs you mentioned — because most Web3 professionals are employed within companies, and these statistics inherently reflect the full employment cost, including social benefits and leave. These data sets represent the actual market conditions for Web3 talent across different regions. That’s why we feel the proposed rates are significantly above the norm — even for high-cost countries, let alone Finland.

We are not questioning the value of your product itself. But as stewards of public funds, we must ask: “Is the cost proportionate to the actual value delivered? Is this an efficient allocation of ecosystem resources?”

We sincerely hope your team can share more background on the internal cost structure and consider adjusting the compensation model to be more in line with industry norms and local benchmarks. This would not only contribute to the long-term sustainability of the ecosystem but also strengthen the community’s confidence in the value your work brings.

Again, thank you for engaging constructively with feedback — we truly believe this kind of open and honest dialogue is what makes the OpenGov process healthy and meaningful.

PolkaWorld has voted NAY on this proposal.

Setting aside the broader question of whether storage is a critical and urgent need in the Polkadot ecosystem — and whether this initiative overlaps with existing solutions like Crust or Filecoin — we believe the salary level proposed by the team is simply too high.

Polkadot Treasury, as a public funding source, should not passively accept flat-rate pricing. There must be room for discussion and accountability on budget justification, especially when the community is funding the work.

While we recognize the technical complexity and depth of the proposal, we would like to raise a concern regarding the cost structure — specifically the rate of $25,000 per FTE, which implies an annual compensation of $300,000 per engineer.

This figure is significantly higher than typical Web3 developer salaries, even in high-cost countries. For context, according to Web3.Career’s latest data:

•	🇳🇴 Norway: ~$85,000/year
•	🇸🇪 Sweden: ~$75,000–80,000/year
•	🇺🇸 United States (highest): ~$130,000–140,000/year

Given that the team is based in Finland, where compensation expectations are likely in line with or below those of Sweden and Norway, the proposed rate appears disproportionately high.

Moreover, this compensation level is equivalent to or exceeds that of CTOs in most Web3 organizations, yet it is being applied uniformly across all engineers in the proposal.

We believe it’s important for Treasury-funded public goods to maintain both technical excellence and cost efficiency. We respectfully request the team to revisit the rate and consider aligning it more closely with regional benchmarks to better serve the long-term sustainability of the ecosystem.

Dear Eiger,

Thank you for submitting your proposal,

Trustless Core has voted AYE.

Below, key findings are presented from the in-depth review of your proposal, highlighting the conclusions that played a significant role in Trustless Core's decision-making process:

While the associated costs are substantial, the necessity of a dedicated team capable of delivering a robust, long-term storage solution native to Polkadot remains clear. Your current consideration of JAM integration is a positive development, but further prioritization of this aspect is advisable—potentially making it the central focus of your proposal.

A key infrastructure component for the ecosystem would be a JAM-based service that enables permanent storage of Data Availability layer data, which is presently retained for approximately one month. Establishing a mechanism through which this data can be persistently stored and seamlessly integrated with other services would significantly enhance interoperability and long-term data accessibility within Polkadot. Strengthening this capability could position this solution as a fundamental layer within the broader network architecture.

Emphasizing JAM integration as a core deliverable is crucial to ensuring alignment with ecosystem needs and optimizing the project’s long-term viability. A well-defined strategy centered around this integration would not only enhance the utility of the proposed solution but also provide a more structured pathway for adoption across various services. By reinforcing its role within the ecosystem, the project can achieve greater relevance and sustainability, making it a foundational component in the long-term evolution of Polkadot's infrastructure.

Best regards,

Trustless Core.

Hey,

I would also like to express my support for Eiger and Polkadot Storage. We are building decentralized systems and have solutions for having the backend decentralized (parachains, contracts, etc). However, what we are missing is a decentralized storage solution. A way to store the UI/user logic in a way that you can always access it, because just having your backend decentralized will not help you when the front end is not reachable. There are also tons of other use cases like a decentralized file stoage/backup solution. Or one of the most obvious use cases would be the usage of a decentralized storage for the Polkadot governance platform :)

All in all, we need a storage solution for Polkadot and Eiger is doing a great job on delivering this.

Thank you for the clarification @Eiger.

Our rating has been updated!

Many thanks for your proposal, Eiger!

We have carefully reviewed your application and are pleased to share our assessment below, prepared using our standardized evaluation methodology.

Summary of our analysis

■ Impact on the Ecosystem

The Polkadot Storage Phase 3 proposal significantly enhances Polkadot’s long-term development by establishing a native storage solution, fostering developer adoption and resilience through decentralized data storage. It addresses a structural weakness by reducing reliance on external networks and promotes interoperability via XCM, supporting parachain development and user retention. Integration with JAM ensures sustained relevance and scalability.

■ Governance Compatibility

The proposal aligns well with the BigSpender origin, fitting large-scale treasury funding for critical infrastructure, despite minor ambiguity in USDt spending limits. Previous Phases 1 and 2 were approved, while Phase 3’s earlier rejection was addressed with improvements, showing meaningful governance use. The resubmission slightly burdens the system but is justified by progress and transparency.

■ Cost-Benefit Ratio

The 1.9 million USDT request is largely proportionate to the strategic benefits of a native storage solution, though its size for a near-complete project raises efficiency concerns. The budget is reasonable compared to prior phases, but the lack of explicit consideration of cheaper alternatives, like IPFS, limits cost optimization. The Treasury gains a scalable, innovative storage layer, enhancing Polkadot’s competitiveness.

■ Transparency and Traceability

Fund usage is clearly communicated with detailed milestones, but the absence of specific KPIs or metrics hinders quantitative tracking. Budgets, timelines, and work packages are meticulously specified, and extensive documentation and bi-weekly reporting ensure robust transparency, though success criteria lack quantifiable measures.

■ Record and Credibility

Eiger has a strong track record, with verifiable contributions like Move integration and completed Polkadot Storage Phases 1 and 2. Their experienced team, supported by public GitHub repositories and positive feedback, demonstrates high capability to deliver the proposed native storage solution.

Conclusion

🔹🔷🔹 vonFlandern 🔹🔷🔹 has therefore voted with: ** AYE **

Our methodology aims to analyze and evaluate OpenGov proposals objectively, effectively, and transparently, establishing clear decision-making foundations for our votes while making our process visible to the community.

Hey @OG_Tracker , phase 3 was estimated as "7 months from phase 2 completion" in the original proposal but I had just updated the text couple of days to reflect the latest status, thanks for pointing it out, I clarified it now. Either way the detailed breakdown in the charts remains the same and contains the timeline for each task, for example page 33. Let me know if you have more questions.

OG Tracker Rating 3/3

Clear display of deliverables✅

• polka-index
• polka-fetch
• Deployment
• Delia
• Gregor

Clear display of a valid direct point of contact✅

• Email: [email protected] + [email protected]

Clear display of proposal’s duration✅

• The duration of this proposal is 7 months.

OGT Rating aims to help voters make better informed decisions and direct proposers towards certain common-good practices. We are providing feedback based on 3 simple yet crucial criteria which we believe should be included in every OpenGov referenda.

Hi everyone,

we have discussed extensively with Eiger and we are pleased with the progress so far.

We are supporting funding this proposal "Phase 3" and will support "Phase 4". Phase 4 is the first milestones that propose a product more than a prototype and start to go into the fundamental question for storage: decentralized properties but also pricing (GB/month, IO/s month and QoS).

Why do we suport them? - We need better storage on Polkadot. Storage is fundational like Compute. But without a strong storage solution, then you can only build product that can fit onchain and that's fine for DeFI but not for a lot of things. - Eiger ways of working and commitment to Polkadot is great (no new token, deliver what they promised), Parity has also enough to do with the Compute part and is happy to have a strong partner that can "get it done". - Robust storage model (decentralized with proof which you do not find everywhere)

Pierre

Note: storage is an expensive business. Building a distributed storage solution is hard and making it decentralized is harder. We expect to see a few milestones before this is a hardened and scalable solution. We plan to do it step by step and come back to you all each time. We also plan to get some prototype of product build on top to see how the system behave and to define a powerfull but easy to use interface. You should see some other proposals soonish for building on top of it services like a on chain password manager or a personal photo system proposed by other builders in the ecosystem.

Pierre from Parity