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)
Proposal Passed
3
of 3Summary
0%
Aye
0%
Nay
Aye (52)0.0 DOT
Support0.0 DOT
Nay (64)0.0 DOT
Voting Data
Approval%
Support%
Threshold0.00%
Threshold0.00%
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.

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.