Trust and security model
RUFF provides verifiable commit-reveal results with an authorized delivery service. Verifiability, availability, and administrative control are separate properties.
For a concrete host-compromise scenario, see How RUFF protects your results. For application controls and additional entropy designs, see Secure your RUFF integration.
What a delivered result proves
Section titled “What a delivered result proves”The current hub accepts the link committed to the assigned lane and computes the published result formula. Anyone with reliable chain history can independently verify the original commitment, request, reveal, and result.
This proves consistency of a delivered result with those inputs. Delivery and the confidentiality of lane secrets depend on the operator, as in other commit-reveal designs; see Delivery availability and Result visibility. RUFF uses hash commitments, not a VRF proof.
Roles and powers
Section titled “Roles and powers”| Role | Powers |
|---|---|
| Consumer | Request a result, pay the fee, and handle its own callback and business state. |
| Revealing operator | Holds lane secrets and can calculate a request’s result after the request block exists. Controls whether its service submits delivery. |
| Authorized relayer | Submit fulfill and anchor recovery. Correct evidence is still required. |
| Hub owner | Pause/unpause, manage relayers and lanes, set tariffs and limits, and withdraw hub funds. |
| Proxy administration | Upgrade the implementation through the configured timelock. |
| Public observer | Read and verify results; expire requests beyond the history window. |
Knowing a correct seed does not authorize delivery. The current design has no public-delivery fallback or priority window that later opens delivery to everyone.
Delivery availability
Section titled “Delivery availability”The operator learns a result once the request block exists. Under the deployed implementation, the commitment fixes which result each request receives: the operator can deliver or withhold it, but cannot select a different valid number. A missing delivery is visible on-chain: the request stays Pending, and after more than 8191 blocks anyone can close it with expire.
Consumers must handle requests that expire without a result. The request fee pays for the delivery attempt and is not refunded on expiry.
Result visibility
Section titled “Result visibility”A result can become public before the consumer callback runs: a reveal may be visible before inclusion, and revealing a later link exposes earlier links from the same lane.
Fix participants and outcome-affecting parameters in the requesting transaction. Do not allow a user to take an outcome-dependent action while delivery is pending merely because the callback has not executed.
Pause and upgrades
Section titled “Pause and upgrades”The current pause switch stops new requests, fulfillment, and anchor recovery. Expiry remains available.
The mainnet hub is owned by the 2-of-3 Safe 0x5B1Ef0E6b331D82E59D421ddC24B2a2759ABD51A. ProxyAdmin is owned by the 600-second timelock 0xbEd892A7015eF084094af82de425e44d3e7Ef4A3; the Safe is its sole proposer, executor, and canceller. The delay applies to implementation upgrades. The Safe’s direct hub controls, such as pausing, changing relayers, and setting tariffs, do not go through that timelock.
The timelock delays an upgrade; it does not remove the authority to replace the code. Deployment addresses identify each contract.
Monitor implementation upgrades and timelock scheduling. Strict historical verification reads old events independently of today’s getters, while comparing the current state separately.
Chain and RPC assumptions
Section titled “Chain and RPC assumptions”The result uses the canonical request block hash. Chain integrity and the reliability of the RPC data used by a verifier remain assumptions. Event-based verification through a single RPC does not authenticate a dishonest RPC by itself.
The relayer checks chain IDs, endpoint freshness, request-log completeness, and matching pinned block hashes when independent endpoints are available. These checks detect several failure modes before the service submits a delivery.
Consumer responsibilities
Section titled “Consumer responsibilities”- Bind each sequence to an existing application action and process it once.
- Accept callbacks only from the configured hub.
- Budget callback gas and provide a recovery path for a stored result.
- Treat zero as a valid result and inspect the request status.
- Define application behavior for expiry, pauses, and upgrades.
The consumer guide implements result storage and callback recovery without prescribing game or payment rules.