Polkadot Storage: Phase 3/3
Thank you everyone for supporting us in Phase 1 and Phase 2. Happy to share that we have completed the work for phase 2. Check out the book, the repo and our weekly progress updates on the Polkadot forum.
As a side note we are happy to share that we are the first team to submit a PR for review for reaching JAM Milestone 1 with our JAM client Strawberry 🍓. We are very excited to turn this vision into executable code.
For this phase 3 we are incorporating feedback gathered during phase 2 and requesting USDT instead of DOT. Given the current market conditions and the community optimism on the future of the DOT price, we believe asking for stables is now the optimal choice for the treasury.
One more thing: During phase 2 we looked at integrating JAM data availability with Polkadot Storage so that it would serve as the underlying storage layer for resupply of unrequested data that needs to be provided to validators on request. What if we used Polkadot Storage as the archival layer of all DA networks such as Celestia, EigenDA, Avail and more. As you know data availability networks give you publishing guarantees but not archival. As contributors to Celestia stack, we are familiar with the codebase and are exploring adding support to take historical snapshots, import, export and archive into Polkadot Storage. Historical data is useful for looking past the retention window, explorers, rollup developers etc. So in short: Storing all DA blockchains archival data into Polkadot Storage, why not.
Links:
- Code https://github.com/eigerco/polka-storage/
- Phase 1/3 https://polkadot.polkassembly.io/referenda/494
- Phase 2/3 https://polkadot.polkassembly.io/referenda/1150
- Full proposal https://docs.google.com/document/d/16SZXvXyBRd-oEMIbgAid_vaxTuKzDlxuNc9CwSq3Lq0/edit
- Thinking about JAM DA integration https://docs.google.com/document/d/1L1jlMI9-KOfxMYUMQVeq0tPNtz1fitxTXlg6gKwjXnM/edit?usp=sharing
- Weekly dev updates https://forum.polkadot.network/t/polkadot-native-storage-updates/7021
- Research on native storage we first did in 2021 but there were limitations with collators back then. We returned to this topic in 2023 and got a grant from W3F to figure out how.
- Initial research pre-implementation https://github.com/eigerco/polkadot-native-storage/blob/main/doc/report/polkadot-native-storage-v1.0.0.pdf
- Forum discussion https://forum.polkadot.network/t/polkadot-native-storage/4551
Comments (9)
Requested
Proposal Failed
Summary
0%
Aye
0%
Nay
Aye (52)0.0 DOT
Support0.0 DOT
Nay (64)0.0 DOT
Although we had originally cast a vote of NAY, after extensive internal deliberation and discussion with the team, we have decided to move to a position of ABSTAIN.
As enterprise grade infrastructure providers who have a good deal of experience in the decentralized storage domain (including Filecoin, Arweave, Walrus and other major protocols), we would like to both share the following feedback with the Eiger team and broader Polkadot community and offer some rationale for the change of our vote:
Firstly, we believe that it is important to handle in-process milestone-based treasury proposals (especially those proposing a common good) with some deference to prior governance approvals, regardless of our position as a current DV. While this does not mean that all proposals should become automatic “AYES”, we do believe it is appropriate for us to shift our starting bias toward “ABSTAIN” in this context.
As to the proposal itself:
On the “AYE” side, we very much believe that there is significant value in an integrated storage primitive for Polkadot, and we value the time, attention, and effort that has been put into this endeavor by the Eiger team. The team clearly consists of professionals who have worked with a number of notable blockchain ecosystems, and they have done their due diligence both with respect to Polkadot and providing some granular visibility as to their progress. Additionally, we commend their efforts for working alongside the Web3 Foundation through an original grant that studied the feasibility of this initiative. We recognize that this will be a needed public good in the future, especially once JAM fully emerges and starts to gain traction. There will be a clear need for storing data that can be accessed by users, builders, and the dApps themselves in order to allow the system to flourish with high performance.
On the NAY side, there were a few aspects of this proposal that we could not overlook and why we could not unconditionally endorse the referendum in its current state. Our team questions the choice of modeling much of the architecture after Filecoin, a decentralized storage protocol that has a number of well-researched challenges when it comes to data retrieval in particular. Several of our team members noted that given these infirmities (for example, Filecoin still struggles to find a true business case) the proposal is closer to a research initiative, with limited direct visibility to a meaningful ROI. We also note that the individual cost for FTEs supporting this proposal is built upon $25K per developer/month. While this is an appropriate cost in our view for senior blockchain developers, it is excessive for such functions as protocol research, general development or administrative support. We would ideally like to see proposals such as this one offer greater audit visibility into the actual hours spent on the project by functional discipline and category of developer experience.
Overall, we believe that chain-integrated storage is a very worthwhile pursuit for the Polkadot ecosystem and in the event that this proposal does not pass, we would welcome an alternative proposal from the Eiger team that directly targets an initial use case for their proposed storage system. Ideally, we would like to see a more Polkadot-bespoke storage primitive that will address the particular needs of JAM, while also providing similar cutting edge tech rather than relying on old archetypes for decentralized storage that still struggle to find product market fit.

@LuckyFridayGovProxy Thank you for the due diligence and engaging with us on a deeper technical level.
> we very much believe that there is significant value in an integrated storage primitive for Polkadot
Happy to hear this.
> Filecoin: challenges when it comes to data retrieval in particular
Although we do use some ideas such as Proof of Space-Time and Proof of Replication to ensure data storage, we don't want to model Filecoin. For us it was important to get started and have an initial design to start building. We are evolving the design as time goes by, targeting those limitations one by one which is why we value your feedback, adjusting it to JAM architecture and overall tailoring it to serve Polkadot.
So thank you for the comprehensive review and feedback.
ChaosDAO would like to provide the following feedback from our community. We offer this feedback voluntarily in the spirit of OpenGov, in order to help teams improve their proposals so we can all build the network together.
ChaosDAO votes as a collective based on the results of our anonymous internal voting procedures. Our members are not required to provide any feedback about why they have voted in a particular direction. Similarly, to respect our members' right to anonymity, we will not be sharing the names of individuals who have chosen to voluntarily provide feedback. You can find out more about how we vote and how to get in contact with us here: https://x.com/ChaosDAO/status/1762986093316587995.
@ChaosDAO
Thank you for sharing the feedback, appreciate it.
It is indeed a high cost but this is a result of the amount of effort it takes to build a whole storage network, this is comparable to people launching a new L1, it's just that we are not creating a new token just adding this to Polkadot so it might be perceived as a smaller endeavor.
All our breakdowns and costs have been listed transparently in the proposal doc since January. About the long-term utility, we accept that there are always improvements to do in communicating these but at the same time we are the first and only team to evolve our design to fit the new JAM architecture and serve in the new vertical stack.
Yes that's correct, Crust is an incentivization layer on top of IPFS. We are tailoring this native storage to serve Polkadot and JAM architecture because there are limitations of what you can do when you rely on an existing tech stack. Also no CRU or FIL, just DOT.
Please see above the evaluation from Lucky Friday: “we very much believe that there is significant value in an integrated storage primitive for Polkadot” They have technical experts in the team that evaluated the idea.
Again, thank you for engaging and sharing.