> For the complete documentation index, see [llms.txt](https://ovro.gitbook.io/ovro-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ovro.gitbook.io/ovro-docs/security/infrastructure.md).

# Infrastructure

What runs off-chain, what it can and cannot do, and what happens if it stops.

The contracts hold the money and make the decisions. Everything off-chain is replaceable, and none of it can pick a winner or move player funds.

## Components

| Component                    | What it does                                                                                                                                                          | If it stops                                                                                                               |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Website** ovro.fun         | Reads the chain and prepares transactions for your wallet. No accounts, no database of users, no tracking.                                                            | Use the contracts through the explorer, see [Using OVRO without the website](/ovro-docs/protocol/without-the-website.md). |
| **RPC gateway** ovro.fun/rpc | Serves blockchain reads for the site with caching and rate limits, in front of Robinhood Chain's official RPC. It can only relay public data and signed transactions. | Your wallet's own RPC keeps working for transactions.                                                                     |
| **Keeper**                   | Automation: closes expired rounds, requests randomness, publishes drand beacons, forwards fees, executes buybacks.                                                    | Every one of these calls is permissionless. The site shows *Close round* and *Reveal winner* buttons to anyone.           |
| **drand relays**             | Serve the public randomness beacon over HTTP. Several independent relays are used.                                                                                    | Any relay works; the contract verifies the signature itself.                                                              |

The website, gateway and keeper run on OVRO's own server. The site does not use WalletConnect or third-party analytics.

## The keeper's limits

The keeper is a separate low-balance wallet that only pays gas.

* On the raffle it has **no role**: it calls the same public functions as anyone.
* After the token activation it holds `KEEPER_ROLE` on the buyback executor. It can only run a buyback within on-chain limits: a minimum output checked against the market price (maximum slippage capped at 15% in the contract), a maximum ETH per buyback, and the bought $OVRO is burned in the same transaction.
* If its key were compromised, the Safe can pause buybacks immediately and replace the keeper through the timelock. Player funds are never reachable with this key.

## Randomness timing

The draw commits to a drand round about 60 seconds in the future (20 rounds at 3 seconds each). If no beacon is delivered within 1 hour, anyone can request new randomness. After 7 days without a draw, anyone can cancel the round and everyone is refunded.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://ovro.gitbook.io/ovro-docs/security/infrastructure.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.