Ideal Network: The Randomness Layer for Polkadot's World Computer
Beneficiary:Ideal Network: The Randomness Layer for Polkadot's World Computer
We're excited to propose the Ideal Network (IDN), a foundational randomness infrastructure for Polkadot's ecosystem.
The team, formed during the Polkadot Blockchain Academy in Buenos Aires, includes Juan Girini (former Parity FRAME Core Engineer), Tony Riemer (Lead Protocol Engineer), Carlos Montoya (Serial Entrepreneur), and Coleman Irby (Software Engineer).
>> Full proposal available here <<
TL;DR
We're requesting 300,250 USDC over three months to deliver:
- Trustless Drand Bridge
- Cross-chain randomness delivery infrastructure
- Security audit by SRLabs
- Network deployment and maintenance
The Problem
Polkadot's ecosystem lacks a reliable method for generating frequent, high-quality random values, critical for creating fair and secure decentralized applications. The existing randomness mechanisms are either vulnerable to manipulation, produced infrequently, or costly. This limitation makes it difficult for developers on Polkadot to build fair systems like unbiased gaming platforms, secure DeFi tools or front-running-free transaction pools where economically sustainable and low-latency randomness is required.
The Ideal Network
The Ideal Network (IDN) will unlock publicly verifiable randomness for Polkadot's World Computer, introducing a game-changing infrastructure that solves critical blockchain challenges. We're building a trustless bridge to the Drand distributed randomness beacon, enabling a standardized randomness layer that delivers secure, verifiable randomness at a fraction of the cost of existing solutions like Chainlink VRF.
The potential is massive:
- Dramatically lower cost and lower latency for access to secure verifiable randomness compared to existing solutions
- Enable new use cases across Web3
- Distribute randomness to parachains on-demand or via subscription
- Export randomness to other blockchain ecosystems
- Unlock timelock encryption capabilities
Use Cases
By providing publicly verifiable on-chain randomness, the Ideal Network enables use cases across multiple domains including secure network consensus and governance, fair DeFi mechanisms, provably random gaming experiences, unbiased and dealer-free gambling, transparent NFT generation, front-running-resistant transaction pools.
Beyond randomness, IDN introduces timelock encryption, a cryptographic mechanism that allows messages to be securely encrypted and revealed only at specific future blocks. This capability opens up entirely new possibilities for blockchain applications, enabling non-interactive multi-party interactions like trustless atomic asset swaps, private delayed transactions, and protocols that were previously infeasible like keyless crypto wallets and sealed-bid auctions.
The possibilities are boundless, limited only by the creativity of developers.
Traction
The work done is supported through collaborations with Web3 Foundation, NIST, and the University of Colorado. We've completed a Web3 Foundation grant, participated in the Decentralized Futures program, and received retroactive funding from the Kusama treasury.
Several projects have expressed interest in integration, including:
 Asset Hub | Parity's Contracts team seeks to integrate high-quality randomness into Asset Hub through precompiles for secure contract features. Their vision focuses on providing developers with a simple, cost-effective interface to request random bytes, dramatically reducing costs compared to existing solutions like Chainlink VRF. |
|---|---|
 Bittensor | Bittensor, a Substrate-based blockchain for decentralized machine learning, has already integrated the Drand-bridge pallet and timelock encryption bindings into their commit-reveal V3 scheme that went into production. This collaboration showcases IDN's practical utility in enhancing the security of decentralized machine learning networks. |
 ChainSafe | ChainSafe has expressed interest in collaborating to explore blockchain-native gaming frameworks, leveraging IDN’s timelock encryption and verifiable randomness capabilities. |
 PolkaStorage | PolkaStorage is exploring randomness solutions for their consensus system. They require secure randomness for their Storage Challenge Mechanism, Proof of Replication (PoRep), and Proof of Spacetime (PoSt) to prevent storage providers from discarding files or pre-computing fake proofs. |
Community Discussions and Feedback
Contact
- Discord: https://discord.gg/phZvQkzU2a
- Element: https://matrix.to/#/#idn-community:matrix.org
- Email: [email protected]
- Website: https://idealabs.network
We welcome your questions and feedback.
Comments (12)
Proposal Passed
3
of 3Summary
0%
Aye
0%
Nay
Aye (75)0.0 DOT
Support0.0 DOT
Nay (18)0.0 DOT
Voting Data
Approval%
Support%
Threshold0.00%
Threshold0.00%
Comments (12)
I have voted AYE.
This is something BIG with massive potential that would benefit the entire ecosystem.
With this infrastructure, Polkadot would stand out from the rest. Other ecosystems don't offer low-cost, low-latency verifiable randomness and timelock encryption, which opens the door for innovation to current Polkadot developers and attracts projects from different ecosystems.
This seems to be a similar project to Nois on Cosmos. Randomness is something that projects will require in order to ensure fairness in their applications. Based on the previous case, Nois, we would like to ask some questions about adoption, compatibility and future support which were the main issues that this approach had on Cosmos.
- Adoption. The adoption of Nois was limited mostly due to the Luna collapse which affected Cosmos the most and it never recovered. But the most evident issue outside the macro picture was that some blockchains like Stargaze used Nois as a source of randomness whereas others, specially dapps just went straight to the Drand API to connect to the source of randomness thus bypassing the blockchain completely. This makes it evident that the clients for Ideal would also be limited to parachains and large projects. A secondary limiting factor was that Nois was compatible mostly for IBC blockchains. How is Ideal Network planning to reach as many projects as possible? Within Polkadot and outside of it (more on this on paragraph 2).
- Compatibility. Based on the paragraph 1, compatibility outside of IBC chains was the second most important factor against the expansion of Nois. Would Ideal Network be considering actively integrating with Hyperbridge and/or Snowbridge to also "export" randomness from Ideal Network into supported EVM chains? It seems like the latency and transfer times would make it possible to relay a message through Hyperbridge to EVM chains. We need to put an emphasis on actively integrating as some referenda in the past have just agreed to some terms without ever delivering them.
- Future Support. We have seen other projects to move goalposts after funding as well as abandoning the project completely as soon as it's delivered so we need to have crystal clear assurances about the future development costs of Ideal network and the maintenance and support costs both in human terms and monetary terms. We are policing heavily against abandonware, unknown maintenance costs and against increase of costs of future deliveries. So knowing these costs in advance would help. In the same vein, is Ideal considering funding through a token launch like Nois did? Or does it plan to remain a common goods project within Polkadot's treasury support? Tokenization after failed public funding is understandable but tokenization without treasury swaps and with treasury support is hard to vouch for.
Looking forward to hearing your answers and future plans.
I have voted AYE.
This is something BIG with massive potential that would benefit the entire ecosystem.
With this infrastructure, Polkadot would stand out from the rest. Other ecosystems don't offer low-cost, low-latency verifiable randomness and timelock encryption, which opens the door for innovation to current Polkadot developers and attracts projects from different ecosystems.
This seems to be a similar project to Nois on Cosmos. Randomness is something that projects will require in order to ensure fairness in their applications. Based on the previous case, Nois, we would like to ask some questions about adoption, compatibility and future support which were the main issues that this approach had on Cosmos.
Looking forward to hearing your answers and future plans.