# Prevrandao Security Analysis

## Overview

`block.prevrandao`(EIP-4399) is a block-level pseudo-random number introduced after Ethereum’s Merge. Although it provides a convenient solution for on-chain randomness, it also involves some security considerations. This article analyzes the security of Prevrandao and the protective measures of MemeDice in depth.

***

## What is Prevrandao?

### Technical Background

Before Ethereum’s Merge (The Merge),`block.difficulty` represented the mining difficulty of a block. After the Merge, Ethereum switched from PoW to PoS,`block.difficulty` the field was redefined as `prevrandao`(EIP-4399).

```
Before the Merge: block.difficulty = mining difficulty (predictable)
After the Merge: block.difficulty = prevrandao (pseudo-random number)
```

### RANDAO Mechanism

`prevrandao` The value of comes from Ethereum’s RANDAO accumulator:

```mermaid
graph LR
    A[Validator 1<br/>submit reveal] --> B[RANDAO mix]
    C[Validator 2<br/>submit reveal] --> B
    D[Validator 3<br/>submit reveal] --> B
    B --> E[prevrandao<br/>used by the next block]
    
    style B fill:#4F46E5,color:#fff
    style E fill:#059669,color:#fff
```

In each epoch, the selected validator must submit a RANDAO reveal value, which is XORed with the previous RANDAO mixed value to produce a new `prevrandao`.

***

## Security Analysis

### ✅ Security for Ordinary Users

For ordinary users (non-validators), Prevrandao is secure:

| Security Property | Description                                                    |
| ----------------- | -------------------------------------------------------------- |
| **Unpredictable** | Ordinary users cannot predict the prevrandao of the next block |
| **Unmanipulable** | Ordinary users cannot affect the value of prevrandao           |
| **Verifiable**    | Anyone can verify through a block explorer                     |

### ⚠️ Validator Manipulation Risk

Block proposers have some ability to manipulate, but the cost of doing so on Ethereum mainnet is extremely high:

#### 1. Selective Block Production

Validators can choose **not to propose a block**(forfeit the right to produce the block), thereby affecting the RANDAO mixing result.

```
Normal flow: validator proposes block → prevrandao = RANDAO_mix XOR reveal
Manipulation flow: validator gives up block production → prevrandao = previous RANDAO_mix (unchanged)
```

**Cost**: Giving up block production means giving up all rewards for that block (about 0.05 ETH + MEV).

#### 2. Selective Transaction Inclusion

Validators can choose **not include** a certain betting transaction, delaying it until the next block for execution.

```
Block N: validator sees the bet transaction → computes the result → unfavorable → does not include the transaction
Block N+1: another validator includes the transaction → uses a different prevrandao
```

**Cost**: may lose gas fee revenue from the transaction.

#### 3. Economic Analysis of Manipulation

| Factor                       | Description                                                                                  |
| ---------------------------- | -------------------------------------------------------------------------------------------- |
| **Manipulation Cost**        | Forfeiting block rewards (\~0.05 ETH + MEV)                                                  |
| **Manipulation Benefit**     | Depends on the bet amount                                                                    |
| **Manipulation Probability** | Validators have only 1 bit of influence (produce a block or not)                             |
| **Conclusion**               | There is an economic incentive only when the bet amount is much larger than the block reward |

> 💡 **Actual Risk Assessment**: For bets of ordinary size (< 1 ETH), the economic incentive for validator manipulation is very low. Validators would need to give up about 0.05 ETH in block rewards, and they only have 1 bit of influence (a 50% chance to change the outcome).

***

## MemeDice Protection Measures

### 1. EOA Restriction (`onlyEOA`)

The Prevrandao mode requires that the caller must be an **externally owned account (EOA)**; contract calls are not allowed.

```solidity
// Pseudocode
modifier onlyEOA() {
    require(msg.sender == tx.origin, "Only EOA");
    _;
}
```

**Protection Purpose**:

* Prevent **flash loan attacks**: attackers cannot borrow → bet → decide whether to revert based on the result within the same transaction
* Prevent **Contract prediction**: contracts cannot read before the call `block.prevrandao` and decide whether to place a bet

### 2. Bet Limit

The game creator can set a maximum bet amount (`maxBet`), limiting the risk exposure of a single bet.

**Protection Purpose**:

* Reduce the economic incentive for validator manipulation
* Limit the maximum loss for a single bet

### 3. Pool Locking

The amount of bets awaiting settlement is locked (`pendingLockedAmount`), ensuring the pool has enough tokens to pay out.

### 4. Network Restrictions

Prevrandao mode is only available on networks that support `prevrandao` it:

| Network          | Supports Prevrandao | Description                    |
| ---------------- | ------------------- | ------------------------------ |
| Ethereum mainnet | ✅                   | Native support after the Merge |
| BSC              | ❌                   | Not supported, Oracle only     |
| Base             | ✅                   | L2                             |

***

## Security Comparison with Oracle Mode

| Security Dimension                 | Oracle mode                                    | Prevrandao mode                    |
| ---------------------------------- | ---------------------------------------------- | ---------------------------------- |
| **Cryptographic Security**         | ✅ commit-reveal guarantee                      | ⚠️ Depends on the protocol layer   |
| **Validator Manipulation**         | ✅ Not affected                                 | ⚠️ There is a theoretical risk     |
| **flash loan attacks**             | ✅ Asynchronous settlement, cannot be reverted  | ✅ EOA restriction protection       |
| **Oracle single point of failure** | ⚠️ Depends on the Oracle service               | ✅ Does not depend on third parties |
| **Timeout risk**                   | ⚠️ Need to wait if the Oracle does not respond | ✅ Instant settlement               |
| **Verifiability**                  | ✅ commitHash verification                      | ✅ Block explorer verification      |

***

## Why doesn’t BSC support Prevrandao?

BSC (BNB Smart Chain) uses **the Parlia consensus mechanism**(based on PoSA), which is different from Ethereum’s PoS:

* BSC does not implement the RANDAO mechanism
* `block.prevrandao` The value returned on BSC is not random
* Therefore, MemeDice only supports Oracle mode on BSC

***

## Summary

| Conclusion            | Description                                                                      |
| --------------------- | -------------------------------------------------------------------------------- |
| **Ordinary players**  | Prevrandao mode is sufficiently secure, with extremely low manipulation risk     |
| **Large-bet players** | It is recommended to use Oracle mode for cryptographic-level security guarantees |
| **BSC users**         | Can only use Oracle mode                                                         |
| **Pursuing speed**    | Prevrandao mode provides an instant settlement experience                        |

> 💡 **Recommendation**: If you are not sure which mode to choose, the default **Oracle mode** is the safest choice.

***

## Further Reading

* [EIP-4399: Supplant DIFFICULTY opcode with PREVRANDAO](https://eips.ethereum.org/EIPS/eip-4399)
* [Ethereum RANDAO Mechanism](https://eth2book.info/capella/part2/building_blocks/randomness/)

***

## Related links

* ⬅️ Back [Technical Deep Dive Overview](/dapp.meme-en/technical-overview/technical-deep-dive-overview.md)
* 🎲 Learn about [Oracle vs Prevrandao](/dapp.meme-en/technical-overview/oracle-vs-prevrandao.md)
* 🔒 Learn about [Game Security](/dapp.meme-en/technical-overview/game-security.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dapp.meme/dapp.meme-en/technical-overview/prevrandao-security-analysis.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.