How randomness is produced
RUFF returns a bytes32 value. The hub checks a committed seed and combines it with the block that accepted the request and the request’s identity.
Commit a lane
Section titled “Commit a lane”The operator generates a random 32-byte tail and hashes backward:
s[i - 1] = keccak256(s[i])The lane’s head is s[0]. Publishing the head and length commits to the chain before requests use its links. The hub rejects reuse of a previously published head.
Each accepted request receives the next unused index from the active lane. Changing the active lane affects new requests; accepted requests keep their original lane and index.
Bind the request
Section titled “Bind the request”The hub stores the consumer, sequence, lane index, request block, callback gas, and optional user contribution. These fields identify a particular request on a particular hub and chain.
A user contribution is stored with the request and included in the result formula.
Reveal and compute
Section titled “Reveal and compute”In a later block, an authorized relayer submits the committed link. The contract verifies that link against the lane’s established chain and computes:
keccak256( abi.encode( seed, // bytes32: verified effective link requestBlockHash, // bytes32 userContribution,// bytes32 sequence, // uint64 consumer, // address block.chainid, // uint256 address(this) // address: hub proxy ))Verification must use abi.encode, the exact types, and this field order. Packed encoding produces a different preimage.
The hub reads recent hashes through BLOCKHASH and uses EIP-2935 history for older request blocks within its window. Delivery requires a request age of 1–8191 blocks.
Anchors and checkpoints
Section titled “Anchors and checkpoints”An anchor is the latest chain link already verified by the hub. Moving forward verifies at most 4096 hashes in one operation. The hub stores checkpoints every 256 indices to bound the work of deriving earlier links.
For an index at or below the anchor, the hub derives the effective link itself. It ignores the submitted seed in that case. The Revealed event contains the effective link actually used.
When the result becomes knowable
Section titled “When the result becomes knowable”The operator holds the lane secrets and can compute a request’s result once its block hash exists. Observers can compute it when the reveal becomes visible, including before the callback if the reveal is visible in pending transaction data.
A later revealed link also exposes earlier links of the same lane by hashing backward. Consumers must fix outcome-affecting inputs when requesting, rather than treating callback execution as the moment the result first becomes knowable.