Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
Retroactive Treasury Proposal: Ideal Network
Retroactive Treasury Proposal Summary: Ideal Network
Requested Amount: $38,760 USD
Period: July - October 2025
Proponent: Ideal Labs
Full Proposal:
- Following the latest w3f guidelines, we have committed to an immutable version of this proposal using Git: https://github.com/ideal-lab5/proposals/blob/main/Retroactive%20Funding%20Proposal.pdf
- also available at: https://docs.google.com/document/d/1_hp2sPx4l179wzpxptkCkaKCwasCvR60bYcQVYQm7cU/edit?usp=sharing
Contact Information
For any pre-vote questions or concerns, feel free to reach out to the team directly on:
Quick Overview
Ideal Labs is requesting retroactive funding for 340 additional development hours (21% overrun) required to complete production-ready deployment of the Ideal Network randomness infrastructure.
Original funding: $191,520 for 1,680 hours
Actual delivery: 2,020 hours required
This request: $38,760 for the additional 340 hours at $114/hr
Why the Overrun?
The team encountered two major categories of unforeseen technical challenges during deployment:
1. Architecture Redesign (120 hours)
During Paseo testnet deployment in August, we discovered a critical incompatibility with the Cumulus lookahead mechasnism. The initial inherents-based design caused:
- Queue consumption issues with multiple candidate blocks
- Non-deterministic randomness distribution across relay chain forks
Solution: Complete rebuild using Post-Finality Gadget (PFG) architecture to ensure canonical randomness after block finalization.
2. Cross-Chain Security Vulnerabilities (140 hours)
Found four critical security vectors during integration that were outside the initial SR Labs audit scope:
- Root origin privilege escalation
- XCM fee payment economic attacks
- Cross-chain unpaid execution exploits
- XCM origin authentication issues
These ecosystem-level vulnerabilities only emerged during actual multi-chain integration testing.
3. Enhanced Smart Contract Support (30 hours)
Went beyond original scope by integrating contracts pallet directly into IDN with custom chain extensions, enabling zero-cost contract randomness access.
4. Production Economic System (50 hours)
Comprehensive credit system, treasury integration, and fee management required more implementation work than originally estimated.
Key Decision Point
When these issues were discovered in August, the team chose to self-fund completion rather than pause development for 4-6 weeks to request an amended proposal, prioritizing delivery of critical ecosystem infrastructure.
What's Complete
All work is deployed and verifiable through public GitHub commits. The project delivered:
- Production-ready randomness infrastructure
- Security-hardened cross-chain integration
- Native smart contract support
- Sustainable economic model
This is a one-time retroactive request for technical work already completed and delivered.
Comments (8)
We have some pre-vote observations whose answers will be input and used for next week's decision.
The reason being, we would like to see deficit covering referenda being reduced to the minimum or ideally removed completely.
So firstly, hopefully now the answers from the original referendum are revisited, specially paragraph #3
https://polkadot.subsquare.io/referenda/1383#1
That basically asks details of future support and budgets moving forward. We are going to need to revisit the value that this parachain will need in order to be functional on mainnet and for future support. In short, how much and how long it will need to be operational on mainnet. There is a proposed timeline here but an updated timeline and costs for the project hopefully is provided so that we can foresee the costs concretely. This is helpful right now due to the current shape of the treasury.
Secondly, an updated list of the potential clients and users that this parachain will have moving forward. The ones that have shown interest and confirmed ones so that the treasury can be confident in the expenditure moving forward.
Hey @SAXEMBERG,
We appreciate your diligence and observations:
Future funding:
We do not intend to seek additional treasury funding beyond this retroactive request. This referendum covers a one-time overrun from architectural challenges that we self-funded to avoid delaying the delivery. The original proposal provisioned funding for one year of parachain operation on Polkadot, which has not yet begun. We have secured a core but are waiting for a review from the Fellowship before production deployment.
Timeline and roadmap:
IDN is already live on Paseo. Pending the Fellowship’s code review and approval, we will deploy to Polkadot. We’ve revised our roadmap to prioritize EVM compatibility as our next step. This allows the IDN to serve an expanding base of EVM developers instead of competing for a small pool of parachains who may integrate.
Users and demand:
Our focus has shifted from parachain teams to application and contract developers. While parachains can easily roll their own randomness, contracts cannot. As Polkadot attracts EVM devs, they will expect familiar infrastructure (e.g. chainlink VRF equivalents) to be available, a gap IDN naturally fills.
Several parachain teams that initially expressed interest have built interim solutions (e.g. storage-hub). While the many bespoke solutions validate the need for randomness for parachains, they also generate adoption friction, as ‘good enough’ solutions are often… good enough. The IDN, being open source, could be forked and integrated into any parachain’s infrastructure. For contract developers and teams that don’t want to support custom consensus, the IDN provides this as a shared service.
Beyond randomness, while our outreach has indicated a low appetite for encrypted mempools, timelock encryption can also be used to build “coordination” primitives, like sealed-bid auctions, atomic swaps, and other coordination protocols that are difficult to build securely without shared infrastructure. We are in discussions with several EVM-focused teams exploring integration with the IDN (but we can’t disclose more until those conversations mature). We expect to have public commitments to share in early 2026.
I appreciate the work delivered by Ideal Labs and the production-ready deployment of the Ideal Network. However, it is important for the community to carefully consider provenance and attribution of foundational architectural ideas.
The proposal implements advanced randomness distribution, cross-chain finality handling, and native contract integrations that mirror concepts previously documented in prior protocols (e.g., SoulSync / LifeBase primitives such as post-finality randomness, entropy-based VRaaS, keyless wallets, and secure timelock mechanisms).
While the proposal is technically sound, it appears that many critical design elements were already present in prior documented architectures. Community members should ensure that retroactive funding appropriately credits originators of foundational protocol ideas to maintain fairness and intellectual integrity in the ecosystem.
Supporting ecosystem development is valuable, but recognition of prior art is essential for sustainable, honest innovation.
@157h3rC3yeahXdNKW1brxhAiADN8iWrE593HeJvwEooPtWAZ
Thanks for the feedback. Can you please provide further information on SoulSync/LifeBase? I’ve searched and can only find one mention in a w3f grant proposal, making similar (but distinct) claims.
All work done by Ideal Labs is open source and we have accurately attributed any and all licensed dependencies. If we have missed any specific license or attribution we’re happy to correct it. You can reach out at [email protected] or open an issue on github.
Beyond this, concepts like post-finality gadgets, timelock encryption, and verifiable randomness are not novel mechanisms unique to any single project. Our work draws from well established academic literature and existing protocols, which we have cited in our technical documentation. We never claimed to invent these primitives.