Verify a delivered result

Verification needs the chain, hub proxy, sequence number, and deployment block. It needs no lane secret or signing key.

In the explorer

Open RUFF Explorer, select a request, and read its saved verification report. The page identifies the checked block and time, separates historical verification from the contract-state comparison, and provides a JSON download.

The explorer verifies in the background and stores the report. Visitors do not run RPC verification in their browser. A Verified report is the explorer’s recorded check; Pending, Incomplete, Unavailable, or Failed must not be treated as success. See the API reference for those states.

To verify independently of the explorer, use the CLI or SDK below with a separately selected RPC.

Choose a verification mode

Mode	Source of request and commitment data	Use
Strict history	LanePublished, Requested, and Revealed, plus the chain’s request block hash.	Independently reconstruct a delivered result from public history.
Current state	The hub’s current getters, reveal event, and checkpoints.	Inspect the result as reported by the current implementation.

Strict mode compares current getters separately. A later implementation change cannot silently replace the historical inputs used by that check.

Strict CLI verification

With Node 22 or later, verify the mainnet example sequence 106:

RNG_RPC_URL=https://rpc.blockdaemon.mainnet.arc.io npx ruff-hub verify \
  --hub 0x398F839B85DA2945D26EBBD1B3a4784A2F1389AB \
  --sequence 106 --from-block 23355234

The verifier checks event identity, uniqueness and ordering, matching request fields, delivery in the allowed block window, the canonical request block hash, the result formula, and the seed’s hash path to the published lane head.

Use the actual deployment block. A range beginning after the lane was published does not contain enough evidence to establish that commitment.

Interpret the result

Field	Meaning
historical.ok	No check that ran found a contradiction.
historical.complete	The full historical check, including hashing to the published head, succeeded.
historical.commitment	head, over-budget, or not-checked.
historical.failures	Explanations of failed historical checks.
currentState.status	match, mismatch, not-checked, or unavailable.
currentState.matches	true for a match, false for a mismatch, null when unavailable or unchecked.
currentState.differences	Differences found in the current view.

Require both historical.ok and historical.complete for a full historical proof. An ok check marked over-budget is incomplete.

Hashing budget

Strict mode hashes at most 2,000,000 steps by default. Above maxHeadSteps, the result reports over-budget; it does not substitute a checkpoint supplied by the current contract.

Increase --max-head-steps deliberately if the lane index requires it. Use --chunk to reduce log-query ranges when the RPC limits eth_getLogs. Neither setting changes the commitment or the result formula.

TypeScript

Install ruff-hub and viem with npm install ruff-hub viem, then use the public exports:

import type { Address, PublicClient } from 'viem';
import { verifyHistory } from 'ruff-hub';

export async function verifyDeliveredNumber(
  client: PublicClient,
  hub: Address,
  sequence: bigint,
  deploymentBlock: bigint,
) {
  const result = await verifyHistory(client, hub, sequence, {
    fromBlock: deploymentBlock,
    chunk: 10_000n,
    maxHeadSteps: 2_000_000n,
  });

  if (!result.historical.ok || !result.historical.complete) {
    throw new Error('Historical verification is incomplete or failed.');
  }
  if (result.currentState.differences.length > 0) {
    throw new Error('Current hub state differs from the verified history.');
  }
  if (result.currentState.status !== 'match') {
    throw new Error('Current hub state could not be fully checked.');
  }
  return result;
}

Historical failure, a state mismatch, and an unavailable state read mean different things. A current-state mismatch does not invalidate an otherwise complete historical proof, but it needs investigation before relying on the current deployment.

Verification boundaries

This checks a delivered result. It does not prove a delivery-time guarantee or the absence of withheld requests. Use a trusted node or independently checked chain data; the SDK does not establish RPC consensus on your behalf.

CLI exit codes and SDK return types provide the machine-readable interface.