On-chain randomness services have traditionally imposed a major bottleneck on blockchain applications that require fast randomness, by introducing significant lag as participants must wait for confirmations. This lag disrupts the user experience of real-time, interactive dApps such as on-chain games, where responsiveness is critical.

The proposed design of an enshrined VRF aims to address this limitation by tightly integrating VRF generation directly into the rollup protocol. In this design, the rollup sequencer takes on the role of the VRF provider, leveraging its privileged position within the rollup to generate and provide randomness with as short a delay as possible.

With this approach, the minimum delay can potentially be reduced to just single-digit milliseconds. We conduct a side-by-side analysis of the security considerations involved in this design, examining trade-offs between unbiasability and predictability, liveness guarantees, and potential collusion. Additionally, we present an analysis of directions for future work that aim to take full advantage of enshrined VRFs while compensating for their limitations.

What is VRF?

A verifiable random function (VRF) is a pseudorandom function that, given an input \(x\) and a secret key \(\mathtt{sk}\), produces an output \(y\) along with a proof \(\pi\) tied to \(y\) and the public key \(\mathtt{pk}\). This proof allows anyone with \(\mathtt{pk}\) to verify that \(y\) is the correct output derived from \(x\) using \(\mathtt{sk}\), without learning anything about \(\mathtt{sk}\) itself.

Think of a VRF as a public-key version of a keyed-hash function (like HMAC). While HMAC produces an output verifiable only by someone who also knows the secret key, a VRF produces an output that is verifiable by anyone with the public key.

VRFs are particularly suitable for providing randomness on blockchains, this is due to the following key characteristics:

• Unbiasability. The output of a VRF is deterministically computed from the secret key \(\mathtt{sk}\) and the input \(x\).
  • Without \(\mathtt{sk}\), one cannot generate \(y\); without \(x\), one cannot predict \(y\).
  • To control the output \(y\), an adversary must both 1) know \(\mathtt{sk}\), and 2) control the choice of \(x\). As long as no one controls both, the output remains unbiasable.
• Public Verifiability. Using the proof \(\pi\) and the public key \(\mathtt{pk}\), anyone can verify the correctness of an output \(y\).
• Pseudorandomness. For a fixed \(\mathtt{sk}\), the function deterministically maps inputs \(x\) to outputs \(y\), but the mapping appears close to uniform. Each output is equally likely to occur.
• (Un)predictability. No party can learn the output \(y\) before it is generated.
  • Note that the computing party (who holds \(\mathtt{sk}\)) has an advantage: they learn the output before others. In practice, this is often mitigated by having multiple parties coordinate the output generation. Furthermore, any actions tied to the randomness (e.g., betting) are typically frozen before the random value is requested.
• Practicality. Compared to other randomness sources like Verifiable Delay Functions (VDFs), VRFs offer faster generation with lower computational overhead.

Challenges with 3rd-party VRFs

The following diagram illustrates the general architecture of VRF solutions commonly used in practice (e.g., Chainlink, Supra).

• Request. A user’s smart contract requests randomness from the VRF contract, typically funding the request through a pre-paid subscription. The VRF contract then emits an event containing the request details.
• Off-Chain Computation. VRF nodes listen for emitted events and wait for a specified number of block confirmations to mitigate reorganization risks. Then, they generate a VRF output using their secret key share and the request parameters. In some cases, outputs are aggregated across multiple nodes.
• Fulfillment. A node submits the generated random number along with its proof back to the VRF contract on-chain.
• Verification & Callback. The VRF contract verifies the proof against the known public key and delivers the verified random number to the user’s requesting contract via a callback function.

Most VRF solutions experience significant delays because of the mandatory waiting period before output computation. This delay, which often lasts from several seconds to minutes, is necessary to avoid the risks of blockchain reorganization. Worse yet, although the outputs are cryptographically difficult to bias, VRF nodes in many settings can still censor requests by withholding outputs they find unfavorable.

The Growing Needs for (Near) Instant Randomness

Traditional randomness sources are simply too slow for real-time, interactive experiences. The gap between the request and response timestamps is large, resulting in poor UX. Because of this, dApps or on-chain games often use a hybrid approach (combining on- and off-chain sources) for randomness.

RISE’s Shreds offer a user experience that feels like the modern web, with single-digit millisecond latency. This enables real-time (pre)confirmations of users’ transactions, effectively making on-chain games and other latency-sensitive applications feasible. In this context, (near-)instant randomness plays a crucial role.

With (near-)instant randomness, dApps can receive verifiable randomness almost immediately. Players see results instantly, maintaining excitement and delivering a seamless UX. It also enables real-time features. With users taking actions that utilise a VRF seeing results immediately displayed in their front-end, something that was previously not possible with traditional VRFs. This unlocks whole categories of latency‑sensitive experiences.

In gaming, an industry projected to generate over $200B in revenue this year, developers can build on‑chain mechanics that feel as seamless as their Web2 counterparties. Think loot packs, card‑pack pulls, or procedurally generated dungeons with single‑digit‑millisecond randomness for gaming RNG can be resolved before the next frame. This means on-chain games can start to scale to massive user bases that would never notice that the blockchain is being used under the hood.

The same low‑latency guarantee translates to provably fair wagering such as lotteries that can draw the winning number while the ticket modal is still on‑screen or peer‑to‑peer dice games where no one can front‑run the roll. Given that the online betting sector already moves over $100 billion annually, shaving seconds to milliseconds is not just a nice feature, it is a competitive edge that could shift billions on chain via a seamless UX that cuts out the middle man.

Enshrined VRF

Unlike third-party VRFs that wait for L1/L2 confirmations, the sequencer acts as the confirmation entity for L2 transactions. It has the most up-to-date view of the chain state and can respond immediately upon including a request. The core idea of an enshrined VRF is to integrate VRF generation directly into the rollup protocol, executed by the rollup’s sequencer, rather than relying on external services that introduce delays or are subject to censorship.

• Pre-deployed Contract: A pre-deployed contract (e.g., PredeployedVRF.sol) is embedded into the rollup protocol. This contract defines the interface for requesting and receiving verifiable randomness.
• Sequencer as VRF Node: The rollup’s sequencer holds the VRF secret key \(\mathtt{sk}\), paired with a public key \(\mathtt{pk}\) known to the pre-deployed contract. The sequencer is responsible for computing VRF outputs for requests made to this contract.

Enhancing Instancy

The true innovation of Enshrined VRF lies in its potential for extremely low latency, leveraging the sequencer's privileged permissions. The sequencer is the one who has the best knowledge about the possibility of a rollup being re-orged. Therefore, it can provide faster responses compared to 3rd-party services.

• By L2 Blocks. This is the most conservative approach, similar in latency to traditional VRFs. The sequencer includes the request in block \(n\) and the fulfillment in block \(n+k\). Latency is tied to the L2 block time (typically seconds).
• By Shreds. Another idea is to require the sequencer to fulfill a request after a few \(\mathtt{Shreds}\) (e.g, 10 \(\mathtt{Shreds}\) ~ 100ms). The sequencer could fulfill the request within a few \(\mathtt{Shreds}\) of the request being included. This reduces latency to potentially hundreds of milliseconds. This relies on \(\mathtt{Shred}\)-level pre-confirmations being meaningful within the protocol.
• (Sub)atomic Response. Because \(\mathtt{Shreds}\) are the lowest level that users can perceive state changes, the sequencer can fulfill a request (by inserting a transaction at the end of a \(\mathtt{Shred}\)) in the same \(\mathtt{Shred}\) containing the request. As soon as that \(\mathtt{Shred}\) is propagated and processed by nodes/users, the randomness output is available. This pushes latency down to the \(\mathtt{Shred}\) propagation time, potentially just milliseconds. This offers near-instantaneous response from the perspective of L2 state transitions.

Analysis

Incorporating RNG generation with a potentially centralized sequencer introduces specific security considerations.

First, the VRF output \(y\) is determined by \(\mathtt{sk}\) (held by the sequencer) and input \(x\). To maintain unbiasability, the input \(x\) must not be controlled by the sequencer. However, the VRF’s predictability remains: the sequencer, knowing \(\mathtt{sk}\) and the final input \(x\), will know the output \(y\) before anyone else. This weak unpredictability is the primary trade-off for speed. As a mitigation, applications using a VRF service commonly freeze relevant actions before making the randomness request. For example, in a lottery, ticket sales must close before the randomness request for the draw is submitted. This prevents the sequencer (or anyone colluding with it) from exploiting knowledge of the upcoming random number.

Regarding liveness, what if the sequencer simply refuses to generate or fulfill a VRF request, perhaps because the outcome is unfavorable, for example, the results of a large lottery payout. Thankfully, failure to fulfill a valid request according to protocol rules should be detectable and punishable, likely via slashing of the sequencer's stake. The liveness of the VRF service becomes tied to the overall liveness and security assumptions of the rollup itself. If the sequencer does not fulfill any VRF request, this will halt the chain, triggering fault challenges.

Lastly, while potentially cheaper than third-party oracles, enshrined VRF requests still incurs fees paid to the sequencer to compensate for computational load. This might be a new revenue stream for the sequencer.

Future Considerations

This article provides a high-level idea of how to integrate VRF to the rollup protocol. However, there are concerns/questions remained to fully realize this in practice.

• Sequencer Load. Generating VRF proofs is computationally more expensive than simple hashing. The sequencer must perform this cryptography for every randomness request, adding load to its operations. This needs to be benchmarked to ensure it does not become a bottleneck for L2 throughput, especially if aiming for shred-level responses.
• Performance. RISE’s CBP currently pre-executes transactions while they are residing in mempool. The result is then used to create \(\mathtt{Shreds}\) and eventual L2 blocks. With this approach, every time an RNG request is made, a response must be appended to the end of the \(\mathtt{Shred}\) (or one of following \(\mathtt{Shreds}\)), creating a risk of invalidating subsequently pre-executed transactions/\(\mathtt{Shreds}\). Fortunately, the VRF generation logics can be categorized and processed with care to avoid the chance of being conflicted with other transactions.
• Parameter Tuning. Despite its simplicity, the protocol needs well-defined parameters, such as:
  • How is the input \(x\) constructed?
  • What are the exact rules and deadlines for fulfillment?
  • What are the gas costs or fees associated with requests?
  • What are the slashing conditions for non-fulfillment?
• Centralization Concerns. The model places significant trust in the single sequencer entity to faithfully execute the VRF computation. While slashing provides economic deterrence against liveness failures, the inherent information advantage (predictability) remains.
  • This central point of generation contrasts with decentralized oracle networks or VDFs where computation might be distributed or inherently time-locked.
  • Future iterations might explore threshold VRFs distributed among a committee of sequencers/validators if the rollup moves towards decentralizing its sequencing role.
• Collusion Risks. While VRFs are secure as long as one cannot control both \(\mathtt{sk}\) and \(x\), collusion might happen when economically incentivized.
  • Sequencer-User Collusion. Could a user bribe the sequencer to manipulate the VRF input \(x\) (if possible within the protocol rules) or reorder transactions around the VRF request/fulfillment to gain an advantage? This depends heavily on the specific rules for constructing \(x\) (e.g., involvement of L1 data).
  • Sequencer-L1 Proposer Collusion. If the VRF input \(x\) relies on L1 data, could the L2 sequencer collude with an L1 proposer to influence that data? This risk exists for any L2 mechanism relying on L1 data, not just enshrined VRF. The impact depends on how sensitive the VRF input is to manipulable L1 parameters.