The Ideal Network | Polkadot🤝Drand
Bringing verifiable randomness to Polkadot by bridging the Drand verifiable randomness beacon
Web3 systems enforce transparency but they do not guarantee fairness.
Fairness, in the context of a decentralized protocol, means equitable and just outcomes for all participants and stakeholders. Studies have shown that randomness is crucial to eliminating bias and manipulation. Without it, systems are vulnerable, easily gamed or manipulated by insiders, bots, or validators. However, there is a considerable challenge: blockchain runtimes, which are deterministic by design, cannot generate randomness.
To resolve this, blockchains like Polkadot and Algorand rely on verifiable random functions (VRFs), a cryptographic primitive that produces pseudorandom values that can be mathematically verified. They are an essential component in many proof-of-stake systems. But while VRFs are powerful, they are not invulnerable to bias and manipulation when used improperly. Since VRF output is inherently tied to block production, it is not context-free, limiting its portability and re-usability to the ecosystem it was generated in. The VRF producer always knows the output prior to delivery.
Backed by the world’s largest DAO, Polkadot’s OpenGov (Treasury), we’re building the Ideal Network (IDN): A Polkadot parachain bringing Verifiable-Randomness-as-a-Service and timelock encryption (TLE) capabilities to the ecosystem! We are immensely grateful to the Polkadot community, as this work is funded through the Polkadot Treasury. Preliminary work was also funded by the Web3 Foundation.
The IDN bridges Drand’s Quicknet, a distributed randomness beacon based on threshold BLS signatures, to Polkadot. This integration allows parachains to access on-demand verifiable randomness. In addition, Polkadot’s unique architecture ensures that verification of Drand pulses is both time and cost efficient.
For developers, this means:
randomness that is automatically delivered via XCM
support for both ink! smart contracts and FRAME pallets
For anybody who needs verifiable randomness, it means cost-efficient and context-free randomness with cross-chain verifiability. It means access to a new class of trustless coordination protocols made possible with timelock encryption.
Verifiable Randomness on Polkadot
If you’re familiar with the inner-workings of Polkadot, the term ‘verifiable randomness’ should be no stranger. If not, then briefly: verifiable randomness refers to a (pseudo)random value that carries a cryptographic proof of correctness. Verifiable randomness is produced through a verifiable random function (VRF). To put it another way, it let’s us compute randomness in a way that anybody can be convinced that it really is random.
BABE, Polkadot’s proof-of-stake consensus mechanism, uses a VRF to determine who can build the next block. A new random value is stored within each block header that can be efficiently verified for correctness. Parachains can easily access this data, verify it, and use it internally, pretty much at no cost (ex: in the PolkaStorage project).
So why do we need another source of randomness if there is already a readily available and cost-effective solution? While BABE’s randomness is cheap and usually “good enough” for internal parachain logic, it is not without limitations.
Block Withholding & Temporal Guarantees
Even in advanced systems like Polkadot, verifiable randomness is vulnerable to manipulation through block withholding.
When used in downstream protocols, the VRF output generated by a block producer influences the outcome. This means that, since a block producer always knows the VRF output in advance, they can choose to withhold their block if it would produce an unfavorable outcome, letting the next authority try. The more valuable the outcome, the stronger the incentive to game it. It could also be possible to bribe collators to withhold blocks. So, in a high-stakes lottery or election, this becomes a potential attack vector. There is no clear way to prove that this kind of manipulation has happened, creating the potential for protocols that rely on this type of randomness to be front-run ways that can’t be proved.
Drand is a distributed network based on threshold cryptography. As long as at least a threshold of nodes are honest and produce valid signatures, then the beacon can output a verifiable pulse on a fixed-time schedule. The IDN, acting as a Drand oracle, ingests, verifies, and dispatches pulses to subscribers. Thanks to Polkadot’s unique architecture, verification is efficient and low-cost, making it a practical solution for parachains. Importantly, even if the IDN fails to dispatch a pulse due to various factors or attacks, the underlying beacon operates independently, providing a temporal guarantee that cannot be delayed, front-run, or censored.
Context Bound and Non-Portable
For high-stakes, cross-chain protocols relying on randomness, it must be globally unbiasable, publicly verifiable and independent of the context of the system that produced it. BABE’s VRF is tightly bounded to the context of Polkadot’s consensus. It is easy to verify the output of BABE VRF in the context of the relay chain, as signers are well known, block numbers are easily attainable, and the runtime tracks block authorship. However, once you leave Polkadot, verification of BABE VRF becomes brittle, trust-dependent, and difficult scale.
Consider a cross-chain sealed bid auction running on a parachain and an EVM smart contract on Ethereum. The randomness for such a protocol must be:
Publicly Verifiable
Time-Bounded
Unbiasable
BABE’s VRF fails to satisfy these properties outside of Polkadot. As we saw with the potential for block withholding, it is not unbiasable, nor is it strictly time-bounded.
In order to verify a BABE VRF output from another chain, a smart contract would either acquire an enormous computational burden or else surrender its own sovereignty by placing significant trust in Polkadot. To elaborate, verification requires answering the following:
Is the block valid? Is it finalized?
Who signed it? Which VRF key?
Which block number was it? Which slot? Which epoch?
In contrast, a verifiable randomness beacon allows independence from the context of the relay chain. There is no need to validate block finalization or care about consensus. Verifying a pulse only requires a well-known public key and the pulse itself. This simplicity makes it easily portable across chains and ecosystems.
The Ideal Network makes Drand available across Polkadot parachains, providing low-cost, on-demand, and chain-agnostic randomness. Developers don’t need to import or verify Polkadot consensus or place trust in validators; you just verify a signature.
To summarize:
Use BABE VRF randomness for a protocol when:
It is within a Polkadot parachain’s runtime.
The protocol is fairly low-stakes, with risk of bias taken into account.
Use IDN when:
You are building high-stakes protocols where bias-resistance is critical.
The randomness must be portable across chains and ecosystems.
You require trust beyond a parachain runtime.
You are building applications that rely on timing guarantees.
Timelock Encryption and Covert Coordination
So far, we have explored limitations of VRFs and how a randomness beacon can overcome them. Now, we turn to capabilities provided by a randomness beacon that VRFs, like those used in BABE or Chainlink VRF, do not offer: Timelock Encryption.
📦 Encrypt → 🕐 Wait for Beacon Pulse → 🔓 Decrypt
Timelock encryption allows a message to be encrypted “to the future” by specifying a round number of the randomness beacon protocol. When the beacon produces a pulse, the signature within allows the ciphertext to be decrypted. You can think of it like a digital time capsule.
As a primitive, timelock encryption unlocks new paradigms for trustless coordination across parachains. It facilitates covert coordination protocols, where participants in a decentralized protocol can coordinate their actions (e.g. trustless atomic asset swaps) in a non-interactive and asynchronous way.
Today, many protocols rely on commit-reveal schemes to build multiparty coordination protocols, where each participant “locks in” their choice before revealing it later on. While effective in a variety of situations, commit-reveal schemes are inherently interactive and often leak information. Since a commitment is typically the output of a cryptographic hash function, it can sometimes be trivial to brute-force the choice if the input space is small (e.g. voting between two candidates, committing to the price of a token in an oracle).
Timelock encryption enables covert coordination protocols, where traditional commitments are replaced with timelock encrypted ciphertexts submitted before some agreed-upon deadline. Each ciphertext reveals no information about its plaintext until after the deadline. After the deadline each participant’s data can be simultaneously revealed in a non-interactive way; none of the participants need to issue a second transaction and they don’t need to remember their plaintext. In effect, timelock encryption eliminates the drawbacks of a commit-reveal schemes, enabling secure, efficient, and privacy-preserving multiparty protocols that incentivize “truthiness”.
Second-Price Sealed-Bid Auctions
By using timelock encryption to seal bids until a deadline, a SPSBA or Vickrey auction can be constructed. From a game theoretic viewpoint, this scheme incentivizes truth telling.
Secure Voting Schemes
Similar to auctions, each bid is sealed until the given deadline. This reduces the likelihood of results being precomputed (e.g. knowing if X participants voted for the same hash in advance can provide an advantage, timelock encryption eliminates it). Effectively, all votes are private until revealed, with no hash to leak information.
Schelling-based Network
While networks like SchellingCoin attempt to enable an accurate and secure data oracle by using the truth as a Schelling point, it is not without a slew of vulnerabilities. By introducing a timelock encrypted payload in place of hashes and a random shuffle, timelock encryption could enable a secure Schelling-style data oracle.
and countless others. We will post an article in the near future to elaborate on this concept as an ‘online epistemic game’.
Beyond these kinds of protocols, it can be used in novel and unexpected ways, such as in Murmur, a keyless crypto wallet protocol based on timelock encryption and OTP codes.
Next Steps
We have recently started a security audit with SRLabs.
We intend to deploy the Ideal Network to Polkadot towards the end of Q2 2025.
We are actively researching our ‘flagship’ application to accompany our production deployment!
If you’re building coordination tools, trustless games, or novel crypto-economics—we’d love to collaborate!
Discord: https://discord.gg/phZvQkzU2a
Github: https://github.com/ideal-lab5
Website: https://idealabs.network