# Randomness

Blockchain users want randomness for many applications like gaming, NFT mints, lotteries, and more. However, this poses a fundamental challenge to blockchains, which are deterministic computers replicated across many nodes across the globe. Each node needs to produce the exact same output when given the same sequence of inputs.

<figure><img src="/files/hqZiVzDcFisv0Ko9DIqg" alt=""><figcaption></figcaption></figure>

Imagine if an on-chain lottery was deciding whether to mint an NFT to Alice or Bob. If blockchain nodes ran their own randomness and some decided that the NFT would go to Alice, and others to Bob, there would be a state mismatch.

<figure><img src="/files/b5FAOjoWFqsBuEfq5ykn" alt=""><figcaption></figcaption></figure>

This is where oracles come in. An oracle can run the randomness off-chain and then post a single result to the blockchain, ensuring that all nodes agree on the result of the randomness.

<figure><img src="/files/VvEFCi1KYVCekLCqFs4e" alt=""><figcaption></figcaption></figure>

However, as a third-party source of randomness, it's critical to make sure that nefarious actors cannot control the oracle and bias the randomness in their favor.

<figure><img src="/files/lsY5MpB2NSUNrQxRwNjn" alt=""><figcaption></figcaption></figure>

As an oracle provider, Switchboard's network serves as a trusted and verified third-party that can post fair random numbers to the blockchain.

<figure><img src="/files/FzjwQbEW0q1Nik84M5yI" alt=""><figcaption></figcaption></figure>

## Switchboard’s approach

Switchboard leverages Trusted Execution Environments (TEEs), which are protected areas inside of a computer's processing unit that cannot be altered or inspected. This means:

* No one, including the oracle operator, can alter the code that’s running on the TEEs
* No one, including the oracle operator, can see what’s going on inside the chip, only inputs and outputs.

This means that Switchboard oracles can generate safe and fair randomness that is free from malicious influence. As an extra layer of protection, Switchboard network incentives ensure that oracle oeprators that misbehave by experiencing downtime or withholding results can have their $SWTCH stake slashed.

## How to Use Switchboard Randomness

To understand the flow, it's helpful to visualize the following 5 parties.

* **Alice**: blockchain user
* **App**: on-chain application
* **Switchboard Contract**: on-chain contract that handles anything Switchboard-related.
* **Crossbar**: server that helps you talk to oracles
* **Oracle**: generates randomness

<figure><img src="/files/aiqbP0k5zb27cvYFnKAl" alt=""><figcaption></figcaption></figure>

There are two stages, requesting and resolving the randomness.

### Request Randomness

* First, **Alice** talks to the **App** requesting some random event.
* The **App** then generates a randomness request with a unique ID and sends it to the **Switchboard contract**.
* The **Switchboard contract** responds to the **App** with an oracle assignment.
* The **App** responds to **Alice** with the oracle assignment and randomness ID.

### Resolve Randomness

* **Alice** sends the oracle assignment, randomness ID, and some other data to **Crossbar** to get the randomness.
* **Crossbar** asks the **Oracle** to generate randomness.
* The **Oracle** creates a randomness object and sends it to **Crossbar** which passes it back to **Alice**.
* **Alice** sends the randomness object to the **App**.
* The **App** asks the **Switchboard contract** to verify that the randomness it received from Alice is correct.
* If all is well, the **Switchboard contract** sends verification to the **App**, resolving the random event.

## Solana Technical Quick Reference

* **Account structure**: use a Switchboard randomness account (commit/reveal state parsed by `RandomnessAccountData`) plus your app-owned state account/PDA (for app fields like `randomness_account` and `commit_slot`).
* **PDA seeds**: Switchboard randomness account is created with `sb.Randomness.create(...)`. App PDA seeds are app-specific; tutorial examples use `[b"playerState", user.key().as_ref()]` and `[b"stateEscrow"]`.
* **Oracle assignment**: assignment happens through the Switchboard request/commit flow and is checked during reveal/settlement. Store and verify the same randomness account reference across commit and settle.
* **Generation window duration**: treat this as policy-based. A strict freshness policy example is `seed_slot == current_slot - 1`, while less strict policies can be chosen for lower-sensitivity flows.
* **Reveal readiness check**: call `RandomnessAccountData::get_value(clock.slot)`. At settle time, success means randomness is ready; error means not yet resolved.

For complete Solana code (account structs, commit/reveal instruction flow, and slot checks), see the [Randomness Tutorial](/docs-by-chain/solana-svm/randomness/randomness-tutorial.md).

## Next Step

Read the [Randomness Tutorial](/docs-by-chain/solana-svm/randomness/randomness-tutorial.md) for full account structures, PDA examples, and commit/reveal validation patterns.

\--


---

# 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.switchboard.xyz/docs-by-chain/solana-svm/randomness.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.