How RUFF protects your results
The hub verifies the evidence and computes the number on-chain. The relayer submits a committed seed; it does not submit an arbitrary number for your application to accept.
A request fixes the inputs
Section titled “A request fixes the inputs”Before requests use a lane, its hash-chain commitment is published on-chain. Each accepted request receives the next unused link and records its consumer, block, contribution and sequence number.
At delivery, the hub checks the link against that commitment and combines it with the request block hash and request context. A relayer cannot substitute another seed or a block of its choice and still satisfy those checks under the current implementation. Delivering in a different order does not change which link belongs to a request.
The request block hash is determined by the chain. The addresses and sequence bind the result to its request; they are public context, not additional secret randomness. See the exact result formula.
If the relayer server is compromised
Section titled “If the relayer server is compromised”Consider an attacker who controls the relayer host, its database and service keys, while the chain and hub implementation remain intact and the owner’s administration keys remain separate.
| Action | Protection or consequence |
|---|---|
| Submit a different seed for an accepted request | The hub rejects a seed that does not satisfy the assigned commitment. |
| Edit a queued request’s consumer or contribution | The accepted inputs are stored on-chain. Editing the service database does not change them. |
| Replace a stored result through another fulfillment | The request is no longer pending and cannot be fulfilled again. |
| Read the lane secrets available to the service | The attacker can calculate an accepted request’s result once its block hash is known, before delivery. |
| Stop or selectively delay delivery | The commitment does not force the attacker to send a transaction. Requests may expire without a result. |
| Use the relayer’s signing key | The attacker can spend that wallet’s funds and submit valid deliveries. Relayer authorization alone does not grant hub ownership or upgrade rights. |
A compromised relayer server could learn pending results early and stop delivering; it cannot change the result accepted by the intact hub for a fixed request. The integration guide shows how to design for both.
RPC agreement protects a different boundary
Section titled “RPC agreement protects a different boundary”The relayer requires matching HTTP reads from two sources in a pool of at least three independently operated RPC endpoints. WebSocket notifications only wake the scanner; they do not supply the result or its proof.
These sources check observations of the same blockchain. Their responses are not mixed into a pool of independent random values.
Verify a delivered result independently
Section titled “Verify a delivered result independently”The public lane commitment, request, reveal and request block hash let an observer recompute a delivered result. Use historical verification with reliable chain data and require a complete commitment check.
The proof establishes how a delivered number was obtained. It cannot prove that lane secrets never leaked or that every accepted request was delivered. The hub stores a valid result before calling the consumer, so a failed callback can be recovered without requesting a replacement number.
Where the guarantee ends
Section titled “Where the guarantee ends”The guarantee depends on the hash function, chain integrity and the implementation processing the request. A block producer colluding with someone who holds lane secrets could compute a result before publishing its block and decide whether to include that request. This requires both the lane secrets and control over block production. Application rules can also introduce manipulation even when the hub’s number is correct.
Hub ownership and proxy upgrades are separate privileges. The mainnet deployment separates those keys from the relayer and uses a 2-of-3 Safe and a 600-second timelock; see the deployment record. An upgrade can change future contract behavior. Review the full trust and security model for role powers, early disclosure and expiry.